gambit-devs / gambit-devs/gambit-pairing
The manual_pairing_dialog module is far to big and needs to be split up and refactored
- Dominant language
- Python
- Stars
- 9
- Forks
- 3
- PR merge metrics
- No merged PRs in 30d
Description
# The manual pairing module contains many classes:
```
class DraggableListWidget(QtWidgets.QListWidget):
class DroppableByeListWidget(DraggableListWidget):
class DroppableTableWidget(QtWidgets.QTableWidget):
class ManualPairingDialog(QtWidgets.QDialog):
```
And is almost 2000 loc. I started trying to refactor this monolith, but I am not cut out for something so confusing.
## I propose we break it up into smaller reusable modules. The Gambit Pairing package is sure to need to manage players in many a place, and having reusable Widgets for the task is a MUCH more maintainable and logical way to handle the widgets.
so:
```
class DraggableListWidget(QtWidgets.QListWidget):
class DroppableByeListWidget(DraggableListWidget):
class DroppableTableWidget(QtWidgets.QTableWidget):
```
should all be made to be there own file, java style. in the gui/widgets package.
from:
```
widgets
├── header.py
```
to:
```
widgets
├── drag_list.py
├── drag_table.py
├── header.py
```
Creating a class in the same file you create a sub-class of that class and then only using said sub-class in that file is not good practice. We should create the widgets we need to be relatively general, and then sub-class them to add specificity. Which was the idea here I think, but the execution is not maintainable, or reusable.
> We should start with a solid drag-able list that handles setting the cursor states correctly, then build the manual pairing dialog with those parts.
## I also propose we combine drag-gable and drop-able stuff into a omnidirectional drop widget.
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.