Set colors doesn't work on objects that have edit mode reimplemented

[FreeCAD-Bug-Importer]

Issue imported from https://tracker.freecad.org/view.php?id=1954

• Reporter: @j-wiedemann
• Date submitted: 2/8/2015
• FreeCAD version: 0.15
• Category: Bug
• Status: assigned
• Tags: colors

Original report text

It seem that Set colors is not working on objects that have their edit mode reimlemented (Arch, Draft, etc)

Additional information

OS: Ubuntu 14.04.1 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.15.4527 (Git)
Branch: master
Hash: 0da2e4c45a9a259c26abd54c2a35393e1c15696f
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
OCC version: 6.7.1.oce-0.16

Steps to reproduce

Create an Arch Object (Wall, Structure...)
Right clic on it in the tree view
Clic on set colors
Instead of having the task panel to change colors per faces the component task widget is open.

Other bug information

• Priority: normal
• Severity: minor
• Category: Bug
• OS: 14.04 64 bits
• Platform: Linux Ubuntu
• Updated: 2/6/2021

Discussion from Mantis ticket

Comment by jmaustpc 2016-01-20 14:00

In current master from today, "Set colours..."

works for Draft Clone

does not for Draft Array which give the error message "this object is not editable"

Sets an Arch wall into task "Components of this object" and so does Arch Structure and Arch stairs.

Building does not have "set colours" in its context menu at all.

OS: Ubuntu 12.04.5 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.16.6240 (Git)
Build type: Debug
Branch: master
Hash: fa42bc451ab6933a441d7be3680c1d17a25c33e8
Python version: 2.7.3
Qt version: 4.8.2
Coin version: 3.1.3
OCC version: 6.9.1.oce-0.18-dev

---

Comment by @yorikvanhavre 2016-01-31 18:15

I had a better look at this now, the "set colors" dialog uses the different edit modes system (setEdit() can receive a number, allowing the object to have several different edit modes.

This is defined in Mod/Part/ViewProviderExt.cpp L694

However, although that system works in python too (setEdit can receive a number), there is apparently no system to fall back to the C++ setEdit if the python setEdit returns False. (Gui/ViewProviderPythonFeature.cpp L415). If the python setEdit exists, the C++ setEdit is never called, no matter the returned value, unless I'm wrong...

I thought about mimicking the ViewProviderExt above (adding a "return Gui::ViewProviderDocumentObject::setEdit(ModNum);" if the python setEdit returns False) but it's apparently not the right way to do.

I'll investigate further

---

Comment by @luzpaz 2017-01-17 20:01

Forum thread: http://forum.freecadweb.org/viewtopic.php?f=10&t=19989

---

Comment by wmayer 2017-01-19 13:04

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):

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.

---

Comment by Kunda1 2017-10-02 04:42

Related to #5546

[adrianinsaval]

@0penBrain any idea how to tackle this? (given your work on user edit mode)

[wwmayer]

Thinking about this further a good solution could be to do the same as with "display modes" of the view providers.

So, there can be a virtual function getEditModes() that returns a list of strings and these strings are saved with the QAction instances when creating the context-menu. setEdit() must be changed where the second parameter that currently is an int will be replaced with a string.

This avoids the difficulties with int's as described in the older posts above and a string automatically is a speaking name and thus easier to memorize when used in scripts.
Another big advantage is that there is no need to register values in the base class ViewProvuider like it's currently done with the EditMode enum.

[luzpaz]

Related to #5546

[Roy-043]

The object editing problems mentioned here have been resolved. Either in #7970 or #8122, or they were already fixed before those PRs.

[luzpaz]

Thanks @Roy-043! what's left to do in this ticket then ?

[Roy-043]

IMO this ticket can be closed. I'll go ahead and do that next. If any of the other participants disagrees they can reopen it.