oc2k1
25th June 2008, 04:24
In Lumina http://lumina.sourceforge.net I have a QObject based tree that represents the (virtual) world.
The main design problem is that subobject require always simple generator function/slots like addChildFoo(....) that are used by the contextmenu and scripting.
It would be much better if the child object could be registerd without these additional functions. That won't be a problem with some abused c++ code like that:
class A{
static bool v;
public:
A(){
std::cout << "Constructor" << v << std::endl;
}
static bool init(){
std::cout << "init class A" << std::endl;
return true;
}
};
bool A::v = A::init();
int main(int argc, char **argv){
return 0; // do nothing, not really
}
A::init() is called before any regular code will be executed. It won't be a problem to use that mechanism, to register that class on a parent class (really class because no object exist at that time).
Now it would be possible that the parent class has a registered QAction (for a context menu entry) But there is a small issue left:
Either the QAction will be connected with a childclasses create function: Any information about the activating objects get lost.
Or the QAction have to be connected to the activating objects slot: Unfortunately it's also impossible to determine the right QAction, but with QAction derivated class (which knows the activating and child object) it should be solvable.
Without scripting the dynamic glueing at startup is possible, but now theres the scripting problem: It isn't possible to call the non existend slots anymore....
on e solution could be a generic create()....) slot that takes a class name as first argument, but that won't be ideal.
Another problem are objects extended by scripts, there isn't a interfact to a scripted member function....
The ideal solution would be a proxy slot / signal system, where a proxy could be created by with a signature like "slotname(argumenttype,.....)" and always it's activated a matching signal with the signature "slotname_sig(QObject*, argumenttype,.....)" will be emit.
In that case the setup would look like:
* child class registers its QAction contextmenu entry at parent class
* child class registers also a proxy slot+signal at parent class
* main() will be executed
* a new parent class will be created:
* a own instance of the registered QAction will be created (copy) and connected to that proxy slot.
if the context menu is triggered it will call the proxy slot that add the objects pointer to the arguments, so that the createChild slot can be called without problems.
A script function would also be able to call that proxy slot. that acts like a true memberfunction. Although it may handled by something unknown :P
The only problem is the implementation, because the moc has to modified :crying: to add that functionality.....
The main design problem is that subobject require always simple generator function/slots like addChildFoo(....) that are used by the contextmenu and scripting.
It would be much better if the child object could be registerd without these additional functions. That won't be a problem with some abused c++ code like that:
class A{
static bool v;
public:
A(){
std::cout << "Constructor" << v << std::endl;
}
static bool init(){
std::cout << "init class A" << std::endl;
return true;
}
};
bool A::v = A::init();
int main(int argc, char **argv){
return 0; // do nothing, not really
}
A::init() is called before any regular code will be executed. It won't be a problem to use that mechanism, to register that class on a parent class (really class because no object exist at that time).
Now it would be possible that the parent class has a registered QAction (for a context menu entry) But there is a small issue left:
Either the QAction will be connected with a childclasses create function: Any information about the activating objects get lost.
Or the QAction have to be connected to the activating objects slot: Unfortunately it's also impossible to determine the right QAction, but with QAction derivated class (which knows the activating and child object) it should be solvable.
Without scripting the dynamic glueing at startup is possible, but now theres the scripting problem: It isn't possible to call the non existend slots anymore....
on e solution could be a generic create()....) slot that takes a class name as first argument, but that won't be ideal.
Another problem are objects extended by scripts, there isn't a interfact to a scripted member function....
The ideal solution would be a proxy slot / signal system, where a proxy could be created by with a signature like "slotname(argumenttype,.....)" and always it's activated a matching signal with the signature "slotname_sig(QObject*, argumenttype,.....)" will be emit.
In that case the setup would look like:
* child class registers its QAction contextmenu entry at parent class
* child class registers also a proxy slot+signal at parent class
* main() will be executed
* a new parent class will be created:
* a own instance of the registered QAction will be created (copy) and connected to that proxy slot.
if the context menu is triggered it will call the proxy slot that add the objects pointer to the arguments, so that the createChild slot can be called without problems.
A script function would also be able to call that proxy slot. that acts like a true memberfunction. Although it may handled by something unknown :P
The only problem is the implementation, because the moc has to modified :crying: to add that functionality.....