ihm-tswow / bxx Goto Github PK

there's too many function names that have the same names as types etc this is stupid

the automatic reloading is kind of unstable and based on a timer. I often enter a buggy state where it gets stuck reading the lockfile and unable to recover

This is a hackaround:

it shouldn't be necessary to increase references twice, and it suggests something is going wrong with that pyobject for another reason.

we should check overrides in operator classes instead

Most of the time it seems like visual studio finds the debug pdbs fine and I can attach to blender and debug my scripts just fine, but sometimes it doesn't find them. This hasn't happened in a while, but making this issue in case it happens again.

currently have to write bxx::pointer_property<your_type::ref,...> but that shouldn't be necessary, just put the fields directly on the types

lots of code depends on quotes so escape those from names

these are normal methods

Constraints are id, so you can get them as pointers. They can be implemented like this:

namespace bxx
{
    enum class owner_space
    {
        WORLD,
        CUSTOM,
        POSE,
        LOCAL_WITH_PARENT,
        LOCAL
    };

    class constraint : public id
    {
        PYFIELD(bool,active)
        PYFIELD(bool,enabled)
        PYFIELD(float,error_location)
        PYFIELD(float,error_rotation)
        PYFIELD(float,influence)
        PYFIELD(bool,is_override_data)
        PYFIELD(bool,is_valid)
        PYFIELD(bool,mute)
        PYFIELD(std::string,name)
        PYFIELD_STRINGENUM(owner_space,owner_space)
        PYFIELD(bool,show_expanded)
        PYFIELD(object,space_object)
    };
}

This is one of the larger things that I need to do before adding much more to the system right now.

As for the api, we can easily convert between python/id types since python types can just be called as_pointer() and id types can just use get_full_name to access pyobject globally. However, if an id type uses mostly python methods i guess that would be slower if we don't support caching it somehow.

Pros of each type

id_ptr

• fast (no refcounting needed)
• multithreaded
• unsafe. dangling pointers can easily happen = program crash, not good.

python

• safe (though i can still null check id), i can check everything
• can dangling pointers happen? what happens to pyobjects after you delete the object they refer to? At least the program shouldn't crash from that.

Type Hierarchy

• object_base - an object that can somehow resolve a PyObject*. Has convenience methods for call, setattr, getattr etc.
• id - generic object that has get_name and get_full_name, extends object_base and resolves PyObject through eval(get_full_name) etc (could maybe cache that PyObject? since if PyObject is dangling id is too?)
• id_ptr - id that has a pointer (template), this can be initialized with a python_object through as_pointer (it could also cache a raw PyObject*?)
• python_object - refcounted PyObject* wrapper, has convenience extensions python_list and python_dict

How do we get children???? of objects

• This is specific to some id types, not all id types can have children.

WE NEED TO CLEARLY MARK UP PYTHON METHODS IN THE DOCUMENTATION

Should python functions have some py_ prefix to make this clear? what is thread safe...