issue #1954: Set colors doesn't work on objects that have edit mode re-implemented
Please discuss below
Edit: Consequence of issue #477
Bug #1954: Set colors doesn't work on objects that have edit mode reimplemented
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Bug #1954: Set colors doesn't work on objects that have edit mode reimplemented
Last edited by Kunda1 on Fri Jun 30, 2017 12:21 pm, edited 1 time in total.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Bug #1954: Set colors doesn't work on objects that have edit mode reimplemented
@wmayer writes:
At the moment the whole "edit modes" framework is broken by design. When setting up an edit mode for a view provider then two methods are involved:
1. setupContextMenu where a QAction can be added to a QMenu
2. setEdit(int) where an int of the actual edit mode is passed
The difficulty is that inside setupContextMenu a unique integer should be set to the QAction which is still unique when a method invokes the same method of the parent class. And inside setEdit a view provider must know the edit mode numbers it must handle.
With the current implementation when a sub-class wants to handle the edit modes of the base class it must know its implementation.
When thinking about it I guess it would work if setupContextMenu returns an int which is the number of edit modes it handles. Then the sub-class would know from which value to start with.
setEdit should then also return an int and depending on its value a sub-class knows if the base class handled it already.
Example (in pseudo code):
The only important point is that a programmer has to take care to use the correct values in setEdit to be consistent with setupContextMenu. But he doesn't have to know about the implementation of the base class any more.
At the moment the whole "edit modes" framework is broken by design. When setting up an edit mode for a view provider then two methods are involved:
1. setupContextMenu where a QAction can be added to a QMenu
2. setEdit(int) where an int of the actual edit mode is passed
The difficulty is that inside setupContextMenu a unique integer should be set to the QAction which is still unique when a method invokes the same method of the parent class. And inside setEdit a view provider must know the edit mode numbers it must handle.
With the current implementation when a sub-class wants to handle the edit modes of the base class it must know its implementation.
When thinking about it I guess it would work if setupContextMenu returns an int which is the number of edit modes it handles. Then the sub-class would know from which value to start with.
setEdit should then also return an int and depending on its value a sub-class knows if the base class handled it already.
Example (in pseudo code):
Code: Select all
int BaseClass::setupContextMenu(menu)
// add two modes
int id = 0;
QAction* act1 = menu->addAction(...);
act1->setData(QVariant(id++));
QAction* act2 = menu->addAction(...);
act2->setData(QVariant(id++));
return id; // id = 2
int SubClass::setupContextMenu(menu)
int id = BaseClass::setupContextMenu
QAction* act1 = menu->addAction(...);
act1->setData(QVariant(id++));
QAction* act2 = menu->addAction(...);
act2->setData(QVariant(id++));
QAction* act3 = menu->addAction(...);
act3->setData(QVariant(id++));
return id; // id = 5
int BaseClass::setEdit(ModNum)
if ModNum < 2:
// handle it
return ModNum - 2; // the 2 is the number of modes this view provider handles
int SubClass::setEdit(ModNum)
if ModNum < 0 // the base class handled it
return ModNum;
if ModNum < 3:
// handle it
return ModNum - 3;
The only important point is that a programmer has to take care to use the correct values in setEdit to be consistent with setupContextMenu. But he doesn't have to know about the implementation of the base class any more.
Alone you go faster. Together we go farther
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Please mark thread [Solved]
Want to contribute back to FC? Checkout:
'good first issues' | Open TODOs and FIXMEs | How to Help FreeCAD | How to report Bugs
Re: Bug #1954: Set colors doesn't work on objects that have edit mode reimplemented
Hi,
As a woodworker, I wish this could be solved as it would allow me to color code the faces of the wood panel parts, thus easily and visually tracking the face, back, left, right, top and bottom of each one of them.
Bests
As a woodworker, I wish this could be solved as it would allow me to color code the faces of the wood panel parts, thus easily and visually tracking the face, back, left, right, top and bottom of each one of them.
Bests