candycode / qpy Goto Github PK

When an object or type is added to the Python context do allow client code to select which methods and properties are actually added through a filter object or RegExp.

Pass an additional MemeberFilter object to the context which is used to filter members.

E.g.

struct MemberFilter {
    bool MethodAvailable(QObject* obj, const QMetaMethod& mm) const = 0;
    bool PropertyAvailable(QObject* obj, const QMetaProperty& mp) const = 0;
};

Not clear what owned means: could be foreign-owned or Python-owned. Do disambiguate.

Currently a QObject to QObject connection is handled through Python, which means that data are unnecessarily marshaled in/out of qt/python.

Modify connect function to handle the case of qobject-qobject connection.

Do we need to implement the clear and traverse functions to address cyclic garbage collection ?

It should be possible to specify the method instead of the signal signature

Add a version attribute for the QObject wrapper and qpy module. Use git hash or regular number, but in case of a regular number do create a map between git hash and version number.

Disconnecting from an object method doesn't work

Test segfaults some times when calling the PyType_Ready function in PyContext::AddType

Add mapper from Qt methods and properties to Python; this can be used to e.g. transform camel case to PEP-8 compliant names.

Move type declarations out of PyContext since they are needed from PyArguments

Make method pure virtual to force derived implementations to explicitly implement it. This will make errors like registering new QObject derived types without explicitly returning true less likely.

Currently the qpy-test program creates both the qpy functions and the test objects in the same module: add test objects in a module other than qpy

Since all signals are forwarded to the same dispatcher method it is not possible to disconnect a signal from individual objects.

It's probably cleaner to derive PyCBackMethod from QObject and have signals routed to instances of this class. This will also fix the issue of not being able to deleted CBackMethods to maintain the mapping between method id and position in the method array consistent.

Enable support for Q_PROPERTYs defined in QObject types.

Looks like the name of a function that converts PyObjects to QVariantMaps, which will be added anyway int the future. Change name.

Create test cases and expected results for:

• connect
• disconnect
• method invocation
• data types: invocable methods returning the value passed to the method itself

Change file structure like this:

CMakeLists.txt
--test
CMakeListsts.txt
...
--lib
CMakeListsts.txt
...
--include
--detail
--src

Add bash script to iterate over test scripts and compare results with their *-expected results

On Snow Leopard the qpy-test.py code is executed correctly but the program segfaults within Py_Finalize.

It's redundant, since it is always possible to return the type and check if it's a QMetaType::QObjectStar

Now that pyMethods contains also properties the name should change to reflect it.

Currently the Python wrapper for QObjects does not allow derivation; should it be enabled ?

Currently everything is implemented in includes: do split into declaration and implementation

#works
qpy.connect(to, 'aSignal(int)', cback)

#DOESN'T WORK
qpy.connect(to, 'aSignal(int)', aclass.cback)

The method is called but then a segfault occurs.

New constructors for Python <--> Qt types are currently added statically at object construction time, add maps and a registration method to allow client code to register its own value constructors.

In the current implementation method invocators are never removed since they are stored into an array whose index is used as the method id, therefore removing elements invalidates the indices.

e.g.

QMyApp app;
qpy::PyContext py;
...
PyObject* appModule = py.ObjectAsModule(&app); //return module wrapping object instance

After #1 is implemented provide a set of default constructors.