Hi again!
Since you merged my previous PR for the TextBox, I’ve kept working on it and ended up doing a major overhaul. The new version is much more robust, optimized, and feature-rich than the one currently in the repo.
However, before I submit a new PR with these massive improvements, I wanted to discuss a couple of architectural choices to make sure they align with your vision for pygame-widgets.
1. Extracting Widget Styling (TextBoxStyle)
As the widget grew, relying heavily on **kwargs and kwargs.get() inside __init__ became a bottleneck. It creates a "black box" for modern IDEs and static analyzers (like mypy/Pyright) — developers don't get autocompletion for styling parameters, and it's hard to reuse the same theme across multiple widgets.
I'm proposing to move all visual parameters into a separate dataclass.
Something like this:
from dataclasses import dataclass
@dataclass
class TextBoxStyle:
colour: tuple[int, int, int] = (220, 220, 220)
borderThickness: int = 3
fontSize: int = 20
# ... other styling props
Inside the TextBox class, we would use composition (self.style.fontSize).
Crucially, this will maintain 100% backward compatibility. The init method will still accept kwargs and automatically map them to the TextBoxStyle object under the hood, so existing projects using the library won't break.
Do you think this is a good direction for the library's UI components?
2. Migration to PEP 8 (snake_case)
The codebase mostly uses camelCase (e.g., textOffsetTop, borderThickness, getText) instead of the Python standard snake_case.
Maybe it would be better to gradually migrate the code to PEP 8? To avoid breaking backward compatibility for the users, we could implement snake_case variables/methods natively, and use @Property or simple aliases to keep the old camelCase API working (perhaps with a DeprecationWarning for future major releases).
If you'd like to check out the current status of my update, you can find the file in my fork here:
https://github.com/CURROCHKA/PygameWidgets/blob/master/pygame_widgets/textbox_new.py
Alternatively, I can open a Draft PR so it's easier to review and discuss the changes.
Let me know your thoughts on this!
textbox_new.py
Hi again!
Since you merged my previous PR for the
TextBox, I’ve kept working on it and ended up doing a major overhaul. The new version is much more robust, optimized, and feature-rich than the one currently in the repo.However, before I submit a new PR with these massive improvements, I wanted to discuss a couple of architectural choices to make sure they align with your vision for
pygame-widgets.1. Extracting Widget Styling (
TextBoxStyle)As the widget grew, relying heavily on
**kwargsandkwargs.get()inside__init__became a bottleneck. It creates a "black box" for modern IDEs and static analyzers (like mypy/Pyright) — developers don't get autocompletion for styling parameters, and it's hard to reuse the same theme across multiple widgets.I'm proposing to move all visual parameters into a separate
dataclass.Something like this:
Inside the TextBox class, we would use composition (self.style.fontSize).
Crucially, this will maintain 100% backward compatibility. The init method will still accept kwargs and automatically map them to the TextBoxStyle object under the hood, so existing projects using the library won't break.
Do you think this is a good direction for the library's UI components?
2. Migration to PEP 8 (snake_case)
The codebase mostly uses camelCase (e.g., textOffsetTop, borderThickness, getText) instead of the Python standard snake_case.
Maybe it would be better to gradually migrate the code to PEP 8? To avoid breaking backward compatibility for the users, we could implement snake_case variables/methods natively, and use @Property or simple aliases to keep the old camelCase API working (perhaps with a DeprecationWarning for future major releases).
If you'd like to check out the current status of my update, you can find the file in my fork here:
https://github.com/CURROCHKA/PygameWidgets/blob/master/pygame_widgets/textbox_new.py
Alternatively, I can open a Draft PR so it's easier to review and discuss the changes.
Let me know your thoughts on this!
textbox_new.py