wmayer wrote:An alternative way would be to replace the int parameter with a string which gives a brief description (only for internal use) what it is about.
This would indeed make it easier, but not fundamentally change the base problem, no? If you create a subclass, being c++ or python, you would still need to know what are the edit modes implemented by the base class. But I think, anyway, if you make a sub class, you NEED to inform about what the base class does. And when you do, it doesn't matter much if implemented modes are 0, 1 and 5 or "edit geometry", "edit something else" and "change color", because you can discover that easily enough.
*EDIT* Actually not so easily... if the base class is itself a sub class of something else...
Maybe it should be just some code convention? Like, always add a comment or something in view provider code, that says what edit modes are implemented by this VP?
DeepSOIC wrote:4. expose c++ setEdit as a method of viewprovider (btw, does calling selfvp.setEdit(...) cause recursion?.. I didn't try, I assume it does...)
For me this should be automatic, like in Qt when you choose to handle an event or not... Ex: In your VP's setEdit method, you return True if you handled it, or False if you didn't. In that last case, the setEdit of the parent class is called. So you would only need to return False to call the corresponding edit mode of the parent class. This currently works for c++ VPs (I think) but not for python VPs.