2024-04-20 10:32:04 -04:00
|
|
|
#pragma once
|
|
|
|
|
#include "Common.h"
|
|
|
|
|
#include "Python.h"
|
|
|
|
|
#include "structmember.h"
|
|
|
|
|
#include "IndexTexture.h"
|
|
|
|
|
#include "Resources.h"
|
|
|
|
|
#include <list>
|
|
|
|
|
|
|
|
|
|
#include "PyCallable.h"
|
|
|
|
|
#include "PyTexture.h"
|
|
|
|
|
#include "PyColor.h"
|
|
|
|
|
#include "PyVector.h"
|
|
|
|
|
#include "PyFont.h"
|
|
|
|
|
|
|
|
|
|
#include "UIGridPoint.h"
|
|
|
|
|
#include "UIEntity.h"
|
|
|
|
|
#include "UIDrawable.h"
|
|
|
|
|
#include "UIBase.h"
|
|
|
|
|
|
|
|
|
|
class UIGrid: public UIDrawable
|
|
|
|
|
{
|
|
|
|
|
private:
|
|
|
|
|
std::shared_ptr<PyTexture> ptex;
|
|
|
|
|
public:
|
|
|
|
|
UIGrid();
|
|
|
|
|
//UIGrid(int, int, IndexTexture*, float, float, float, float);
|
|
|
|
|
UIGrid(int, int, std::shared_ptr<PyTexture>, sf::Vector2f, sf::Vector2f);
|
|
|
|
|
void update();
|
2025-03-05 20:21:24 -05:00
|
|
|
void render(sf::Vector2f, sf::RenderTarget&) override final;
|
2024-04-20 10:32:04 -04:00
|
|
|
UIGridPoint& at(int, int);
|
|
|
|
|
PyObjectsEnum derived_type() override final;
|
|
|
|
|
//void setSprite(int);
|
|
|
|
|
virtual UIDrawable* click_at(sf::Vector2f point) override final;
|
|
|
|
|
|
|
|
|
|
int grid_x, grid_y;
|
|
|
|
|
//int grid_size; // grid sizes are implied by IndexTexture now
|
|
|
|
|
sf::RectangleShape box;
|
|
|
|
|
float center_x, center_y, zoom;
|
|
|
|
|
//IndexTexture* itex;
|
|
|
|
|
std::shared_ptr<PyTexture> getTexture();
|
|
|
|
|
sf::Sprite sprite, output;
|
|
|
|
|
sf::RenderTexture renderTexture;
|
|
|
|
|
std::vector<UIGridPoint> points;
|
|
|
|
|
std::shared_ptr<std::list<std::shared_ptr<UIEntity>>> entities;
|
|
|
|
|
|
|
|
|
|
static int init(PyUIGridObject* self, PyObject* args, PyObject* kwds);
|
|
|
|
|
static PyObject* get_grid_size(PyUIGridObject* self, void* closure);
|
|
|
|
|
static PyObject* get_position(PyUIGridObject* self, void* closure);
|
|
|
|
|
static int set_position(PyUIGridObject* self, PyObject* value, void* closure);
|
|
|
|
|
static PyObject* get_size(PyUIGridObject* self, void* closure);
|
|
|
|
|
static int set_size(PyUIGridObject* self, PyObject* value, void* closure);
|
|
|
|
|
static PyObject* get_center(PyUIGridObject* self, void* closure);
|
|
|
|
|
static int set_center(PyUIGridObject* self, PyObject* value, void* closure);
|
|
|
|
|
static PyObject* get_float_member(PyUIGridObject* self, void* closure);
|
|
|
|
|
static int set_float_member(PyUIGridObject* self, PyObject* value, void* closure);
|
|
|
|
|
static PyObject* get_texture(PyUIGridObject* self, void* closure);
|
|
|
|
|
static PyObject* py_at(PyUIGridObject* self, PyObject* o);
|
|
|
|
|
static PyMethodDef methods[];
|
|
|
|
|
static PyGetSetDef getsetters[];
|
|
|
|
|
static PyObject* get_children(PyUIGridObject* self, void* closure);
|
2024-04-20 18:33:18 -04:00
|
|
|
static PyObject* repr(PyUIGridObject* self);
|
2024-04-20 10:32:04 -04:00
|
|
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
PyObject_HEAD
|
|
|
|
|
std::shared_ptr<std::list<std::shared_ptr<UIEntity>>> data;
|
|
|
|
|
std::shared_ptr<UIGrid> grid;
|
|
|
|
|
} PyUIEntityCollectionObject;
|
|
|
|
|
|
|
|
|
|
class UIEntityCollection {
|
|
|
|
|
public:
|
|
|
|
|
static PySequenceMethods sqmethods;
|
|
|
|
|
static PyObject* append(PyUIEntityCollectionObject* self, PyObject* o);
|
|
|
|
|
static PyObject* remove(PyUIEntityCollectionObject* self, PyObject* o);
|
|
|
|
|
static PyMethodDef methods[];
|
|
|
|
|
static PyObject* repr(PyUIEntityCollectionObject* self);
|
|
|
|
|
static int init(PyUIEntityCollectionObject* self, PyObject* args, PyObject* kwds);
|
|
|
|
|
static PyObject* iter(PyUIEntityCollectionObject* self);
|
|
|
|
|
static Py_ssize_t len(PyUIEntityCollectionObject* self);
|
|
|
|
|
static PyObject* getitem(PyUIEntityCollectionObject* self, Py_ssize_t index);
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
PyObject_HEAD
|
|
|
|
|
std::shared_ptr<std::list<std::shared_ptr<UIEntity>>> data;
|
|
|
|
|
int index;
|
|
|
|
|
int start_size;
|
|
|
|
|
} PyUIEntityCollectionIterObject;
|
|
|
|
|
|
|
|
|
|
class UIEntityCollectionIter {
|
|
|
|
|
public:
|
|
|
|
|
static int init(PyUIEntityCollectionIterObject* self, PyObject* args, PyObject* kwds);
|
|
|
|
|
static PyObject* next(PyUIEntityCollectionIterObject* self);
|
|
|
|
|
static PyObject* repr(PyUIEntityCollectionIterObject* self);
|
|
|
|
|
static PyObject* getitem(PyUIEntityCollectionObject* self, Py_ssize_t index);
|
|
|
|
|
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
namespace mcrfpydef {
|
|
|
|
|
static PyTypeObject PyUIGridType = {
|
Iterators, other Python C API improvements
closes #72
ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated.
**RPATH updates**
Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer?
The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer.
**New standard object initialization**
PyColor, PyVector
- Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax
- Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp
- Updated PyObject_New usage in UIEntity.cpp
- All object creation now uses module-based type lookups instead of static references
- Created centralized utilities in PyObjectUtils.h
**RAII Wrappers**
automatic reference counting via C++ object lifecycle
- Created PyRAII.h with PyObjectRef and PyTypeRef classes
- These provide automatic reference counting management
- Updated PyColor::from_arg() to demonstrate RAII usage
- Prevents memory leaks and reference counting errors
**Python object base in type defs:**
`.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}`
PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid
**convertDrawableToPython**
replace crazy macro to detect the correct Python type of a UIDrawable instance
- Removed the problematic macro from UIDrawable.h
- Created template-based functions in PyObjectUtils.h
- Updated UICollection.cpp to use local helper function
- The new approach is cleaner, more debuggable, and avoids static type references
**Iterator fixes**
tp_iter on UICollection, UIGrid, UIGridPoint, UISprite
UIGrid logic improved, standard
**List vs Vector usage analysis**
there are different use cases that weren't standardized:
- UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>>
- UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>>
The rationale is currently connected to frequency of expected changes.
* A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed.
* A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
|
|
|
.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0},
|
2024-04-20 10:32:04 -04:00
|
|
|
.tp_name = "mcrfpy.Grid",
|
|
|
|
|
.tp_basicsize = sizeof(PyUIGridObject),
|
|
|
|
|
.tp_itemsize = 0,
|
|
|
|
|
//.tp_dealloc = (destructor)[](PyObject* self)
|
|
|
|
|
//{
|
|
|
|
|
// PyUIGridObject* obj = (PyUIGridObject*)self;
|
|
|
|
|
// obj->data.reset();
|
|
|
|
|
// Py_TYPE(self)->tp_free(self);
|
|
|
|
|
//},
|
|
|
|
|
//TODO - PyUIGrid REPR def:
|
2024-04-20 18:33:18 -04:00
|
|
|
.tp_repr = (reprfunc)UIGrid::repr,
|
2024-04-20 10:32:04 -04:00
|
|
|
//.tp_hash = NULL,
|
|
|
|
|
//.tp_iter
|
|
|
|
|
//.tp_iternext
|
|
|
|
|
.tp_flags = Py_TPFLAGS_DEFAULT,
|
|
|
|
|
.tp_doc = PyDoc_STR("docstring"),
|
|
|
|
|
.tp_methods = UIGrid::methods,
|
|
|
|
|
//.tp_members = UIGrid::members,
|
|
|
|
|
.tp_getset = UIGrid::getsetters,
|
|
|
|
|
//.tp_base = NULL,
|
|
|
|
|
.tp_init = (initproc)UIGrid::init,
|
|
|
|
|
.tp_new = [](PyTypeObject* type, PyObject* args, PyObject* kwds) -> PyObject*
|
|
|
|
|
{
|
|
|
|
|
PyUIGridObject* self = (PyUIGridObject*)type->tp_alloc(type, 0);
|
|
|
|
|
if (self) self->data = std::make_shared<UIGrid>();
|
|
|
|
|
return (PyObject*)self;
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static PyTypeObject PyUIEntityCollectionIterType = {
|
Iterators, other Python C API improvements
closes #72
ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated.
**RPATH updates**
Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer?
The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer.
**New standard object initialization**
PyColor, PyVector
- Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax
- Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp
- Updated PyObject_New usage in UIEntity.cpp
- All object creation now uses module-based type lookups instead of static references
- Created centralized utilities in PyObjectUtils.h
**RAII Wrappers**
automatic reference counting via C++ object lifecycle
- Created PyRAII.h with PyObjectRef and PyTypeRef classes
- These provide automatic reference counting management
- Updated PyColor::from_arg() to demonstrate RAII usage
- Prevents memory leaks and reference counting errors
**Python object base in type defs:**
`.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}`
PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid
**convertDrawableToPython**
replace crazy macro to detect the correct Python type of a UIDrawable instance
- Removed the problematic macro from UIDrawable.h
- Created template-based functions in PyObjectUtils.h
- Updated UICollection.cpp to use local helper function
- The new approach is cleaner, more debuggable, and avoids static type references
**Iterator fixes**
tp_iter on UICollection, UIGrid, UIGridPoint, UISprite
UIGrid logic improved, standard
**List vs Vector usage analysis**
there are different use cases that weren't standardized:
- UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>>
- UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>>
The rationale is currently connected to frequency of expected changes.
* A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed.
* A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
|
|
|
.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0},
|
|
|
|
|
.tp_name = "mcrfpy.UIEntityCollectionIter",
|
2024-04-20 10:32:04 -04:00
|
|
|
.tp_basicsize = sizeof(PyUIEntityCollectionIterObject),
|
|
|
|
|
.tp_itemsize = 0,
|
|
|
|
|
.tp_dealloc = (destructor)[](PyObject* self)
|
|
|
|
|
{
|
|
|
|
|
PyUIEntityCollectionIterObject* obj = (PyUIEntityCollectionIterObject*)self;
|
|
|
|
|
obj->data.reset();
|
|
|
|
|
Py_TYPE(self)->tp_free(self);
|
|
|
|
|
},
|
|
|
|
|
.tp_repr = (reprfunc)UIEntityCollectionIter::repr,
|
|
|
|
|
.tp_flags = Py_TPFLAGS_DEFAULT,
|
|
|
|
|
.tp_doc = PyDoc_STR("Iterator for a collection of UI objects"),
|
Iterators, other Python C API improvements
closes #72
ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated.
**RPATH updates**
Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer?
The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer.
**New standard object initialization**
PyColor, PyVector
- Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax
- Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp
- Updated PyObject_New usage in UIEntity.cpp
- All object creation now uses module-based type lookups instead of static references
- Created centralized utilities in PyObjectUtils.h
**RAII Wrappers**
automatic reference counting via C++ object lifecycle
- Created PyRAII.h with PyObjectRef and PyTypeRef classes
- These provide automatic reference counting management
- Updated PyColor::from_arg() to demonstrate RAII usage
- Prevents memory leaks and reference counting errors
**Python object base in type defs:**
`.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}`
PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid
**convertDrawableToPython**
replace crazy macro to detect the correct Python type of a UIDrawable instance
- Removed the problematic macro from UIDrawable.h
- Created template-based functions in PyObjectUtils.h
- Updated UICollection.cpp to use local helper function
- The new approach is cleaner, more debuggable, and avoids static type references
**Iterator fixes**
tp_iter on UICollection, UIGrid, UIGridPoint, UISprite
UIGrid logic improved, standard
**List vs Vector usage analysis**
there are different use cases that weren't standardized:
- UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>>
- UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>>
The rationale is currently connected to frequency of expected changes.
* A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed.
* A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
|
|
|
.tp_iter = PyObject_SelfIter,
|
2024-04-20 10:32:04 -04:00
|
|
|
.tp_iternext = (iternextfunc)UIEntityCollectionIter::next,
|
|
|
|
|
//.tp_getset = UIEntityCollection::getset,
|
|
|
|
|
.tp_init = (initproc)UIEntityCollectionIter::init, // just raise an exception
|
Iterators, other Python C API improvements
closes #72
ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated.
**RPATH updates**
Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer?
The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer.
**New standard object initialization**
PyColor, PyVector
- Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax
- Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp
- Updated PyObject_New usage in UIEntity.cpp
- All object creation now uses module-based type lookups instead of static references
- Created centralized utilities in PyObjectUtils.h
**RAII Wrappers**
automatic reference counting via C++ object lifecycle
- Created PyRAII.h with PyObjectRef and PyTypeRef classes
- These provide automatic reference counting management
- Updated PyColor::from_arg() to demonstrate RAII usage
- Prevents memory leaks and reference counting errors
**Python object base in type defs:**
`.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}`
PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid
**convertDrawableToPython**
replace crazy macro to detect the correct Python type of a UIDrawable instance
- Removed the problematic macro from UIDrawable.h
- Created template-based functions in PyObjectUtils.h
- Updated UICollection.cpp to use local helper function
- The new approach is cleaner, more debuggable, and avoids static type references
**Iterator fixes**
tp_iter on UICollection, UIGrid, UIGridPoint, UISprite
UIGrid logic improved, standard
**List vs Vector usage analysis**
there are different use cases that weren't standardized:
- UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>>
- UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>>
The rationale is currently connected to frequency of expected changes.
* A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed.
* A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
|
|
|
.tp_alloc = PyType_GenericAlloc,
|
2024-04-20 10:32:04 -04:00
|
|
|
.tp_new = [](PyTypeObject* type, PyObject* args, PyObject* kwds) -> PyObject*
|
|
|
|
|
{
|
|
|
|
|
PyErr_SetString(PyExc_TypeError, "UICollection cannot be instantiated: a C++ data source is required.");
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static PyTypeObject PyUIEntityCollectionType = {
|
Iterators, other Python C API improvements
closes #72
ref #69 - this resolves the "UICollection" (not "UIEntityCollection", perhaps renamed since the issue opened) and "UIEntityCollection" portion. The Grid point based iterators were not updated.
**RPATH updates**
Will this RPATH setting allow McRogueFace to execute using its included "lib" subdirectory after being unzipped on a new computer?
The change from "./lib" to "$ORIGIN/./lib" improves portability. The $ORIGIN token is a special Linux/Unix convention that refers to the directory containing the executable itself. This makes the path relative to the executable's location rather than the current working directory, which means McRogueFace will correctly find its libraries in the lib subdirectory regardless of where it's run from after being unzipped on a new computer.
**New standard object initialization**
PyColor, PyVector
- Fixed all 15 PyTypeObject definitions to use proper designated initializer syntax
- Replaced PyType_GenericAlloc usage in PyColor.cpp and PyVector.cpp
- Updated PyObject_New usage in UIEntity.cpp
- All object creation now uses module-based type lookups instead of static references
- Created centralized utilities in PyObjectUtils.h
**RAII Wrappers**
automatic reference counting via C++ object lifecycle
- Created PyRAII.h with PyObjectRef and PyTypeRef classes
- These provide automatic reference counting management
- Updated PyColor::from_arg() to demonstrate RAII usage
- Prevents memory leaks and reference counting errors
**Python object base in type defs:**
`.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0}`
PyColor, PyTexture, PyVector, UICaption, UICollection, UIEntity, UIFrame, UIGrid
**convertDrawableToPython**
replace crazy macro to detect the correct Python type of a UIDrawable instance
- Removed the problematic macro from UIDrawable.h
- Created template-based functions in PyObjectUtils.h
- Updated UICollection.cpp to use local helper function
- The new approach is cleaner, more debuggable, and avoids static type references
**Iterator fixes**
tp_iter on UICollection, UIGrid, UIGridPoint, UISprite
UIGrid logic improved, standard
**List vs Vector usage analysis**
there are different use cases that weren't standardized:
- UICollection (for Frame children) uses std::vector<std::shared_ptr<UIDrawable>>
- UIEntityCollection (for Grid entities) uses std::list<std::shared_ptr<UIEntity>>
The rationale is currently connected to frequency of expected changes.
* A "UICollection" is likely either all visible or not; it's also likely to be created once and have a static set of contents. They should be contiguous in memory in hopes that this helps rendering speed.
* A "UIEntityCollection" is expected to be rendered as a subset within the visible rectangle of the UIGrid. Scrolling the grid or gameplay logic is likely to frequently create and destroy entities. In general I expect Entity collections to have a much higher common size than UICollections. For these reasons I've made them Lists in hopes that they never have to be reallocated or moved during a frame.
2025-05-31 08:58:52 -04:00
|
|
|
.ob_base = {.ob_base = {.ob_refcnt = 1, .ob_type = NULL}, .ob_size = 0},
|
2024-04-20 10:32:04 -04:00
|
|
|
.tp_name = "mcrfpy.EntityCollection",
|
|
|
|
|
.tp_basicsize = sizeof(PyUIEntityCollectionObject),
|
|
|
|
|
.tp_itemsize = 0,
|
|
|
|
|
.tp_dealloc = (destructor)[](PyObject* self)
|
|
|
|
|
{
|
|
|
|
|
PyUIEntityCollectionObject* obj = (PyUIEntityCollectionObject*)self;
|
|
|
|
|
obj->data.reset();
|
|
|
|
|
Py_TYPE(self)->tp_free(self);
|
|
|
|
|
},
|
|
|
|
|
.tp_repr = (reprfunc)UIEntityCollection::repr,
|
|
|
|
|
.tp_as_sequence = &UIEntityCollection::sqmethods,
|
|
|
|
|
.tp_flags = Py_TPFLAGS_DEFAULT,
|
|
|
|
|
.tp_doc = PyDoc_STR("Iterable, indexable collection of Entities"),
|
|
|
|
|
.tp_iter = (getiterfunc)UIEntityCollection::iter,
|
|
|
|
|
.tp_methods = UIEntityCollection::methods, // append, remove
|
|
|
|
|
//.tp_getset = UIEntityCollection::getset,
|
|
|
|
|
.tp_init = (initproc)UIEntityCollection::init, // just raise an exception
|
|
|
|
|
.tp_new = [](PyTypeObject* type, PyObject* args, PyObject* kwds) -> PyObject*
|
|
|
|
|
{
|
|
|
|
|
// Does PyUIEntityCollectionType need __new__ if it's not supposed to be instantiable by the user?
|
|
|
|
|
// Should I just raise an exception? Or is the uninitialized shared_ptr enough of a blocker?
|
|
|
|
|
PyErr_SetString(PyExc_TypeError, "EntityCollection cannot be instantiated: a C++ data source is required.");
|
|
|
|
|
return NULL;
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
}
|