Create Python base class for UIDrawables, and derive Python UI types from it #71

New Issue

john · 2024-04-13T03:47:13Z

john commented

2024-04-13 03:47:13 +00:00

It just makes good sense to mirror the type hierarchy in both Python and C++.

if .tp_base of each UIDrawable type points to a mcrfpy.Drawable class, then I wouldn't have to do this:

    if (!PyObject_IsInstance(o, (PyObject*)&PyUIFrameType) &&
        !PyObject_IsInstance(o, (PyObject*)&PyUISpriteType) &&
        !PyObject_IsInstance(o, (PyObject*)&PyUICaptionType) &&
        !PyObject_IsInstance(o, (PyObject*)&PyUIGridType)
        )

which is also fragile to new UIDrawable derived classes.

Probably the new base class should be mcrfpy._Drawable, an abstract base class which Python code can't derive from. But I can also define a separate mcrfpy.Drawable class, which derives from the base class, CAN be subclassed, and has a C++ implementation (as UserDrawable or something) to implement the interface by calling Python code.

It would be a good opportunity to test the performance of using a Python rendering function... ...but Python doesn't have draw functions yet, so user render will have to wait.

An additional possibility is making UICollection derive from mcrfpy._Drawable, and allowing users to subclass that - they could define any __init__ they want, manage the collection internally with self.append, self.remove, etc. This would be a great way to keep all render functions in C++ while making it easier to encapsulate behavior requiring multiple UI widgets, like text boxes with captions, dialogue with a sprite that changes or moves, etc.

It just makes good sense to mirror the type hierarchy in both Python and C++. if `.tp_base` of each UIDrawable type points to a `mcrfpy.Drawable` class, then I wouldn't have to do this: ``` if (!PyObject_IsInstance(o, (PyObject*)&PyUIFrameType) && !PyObject_IsInstance(o, (PyObject*)&PyUISpriteType) && !PyObject_IsInstance(o, (PyObject*)&PyUICaptionType) && !PyObject_IsInstance(o, (PyObject*)&PyUIGridType) ) ``` which is also fragile to new UIDrawable derived classes. Probably the new base class should be `mcrfpy._Drawable`, an abstract base class which Python code can't derive from. But I can also define a separate `mcrfpy.Drawable` class, which derives from the base class, CAN be subclassed, and has a C++ implementation (as `UserDrawable` or something) to implement the interface by calling Python code. It would be a good opportunity to test the performance of using a Python rendering function... ...but Python doesn't have draw functions yet, so user render will have to wait. An additional possibility is making UICollection derive from `mcrfpy._Drawable`, and allowing users to subclass that - they could define any `__init__` they want, manage the collection internally with `self.append`, `self.remove`, etc. This would be a great way to keep all render functions in C++ while making it easier to encapsulate behavior requiring multiple UI widgets, like text boxes with captions, dialogue with a sprite that changes or moves, etc.

john added the

Refactoring & Cleanup

Minor Feature

labels 2024-04-13 03:47:13 +00:00

john referenced this issue from a commit

2025-07-06 22:19:03 +00:00

feat: Phase 1 - safe constructors and _Drawable foundation

john referenced this issue from a commit

2025-07-10 02:52:26 +00:00

Squashed commit of 53 Commits: [alpha_streamline_2]

john closed this issue

2025-07-10 02:52:26 +00:00