View Issue Details

IDProjectCategoryView StatusLast Update
0001954FreeCADBugpublic2019-02-24 18:30
ReporterrocknAssigned Towmayer 
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
PlatformLinux UbuntuOS14.04OS Version64 bits
Product Version0.15 
Target Version0.19Fixed in Version 
Summary0001954: Set colors doesn't work on objects that have edit mode reimplemented
DescriptionIt seem that Set colors is not working on objects that have their edit mode reimlemented (Arch, Draft, etc)
Steps To ReproduceCreate 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.
Additional InformationOS: 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
Tagscolors

Relationships

related to 0000477 acknowledged Proper interface for edit modes of view provider 

Activities

jmaustpc

2016-01-20 14:00

manager   ~0006736

Last edited: 2016-01-20 14:01

View 2 revisions

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

yorik

2016-01-31 18:15

administrator   ~0006780

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

Kunda1

2017-01-17 20:01

administrator   ~0007849

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

wmayer

2017-01-19 13:04

administrator   ~0007874

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.

Kunda1

2017-10-02 04:42

administrator   ~0010236

Related to 0000477

Issue History

Date Modified Username Field Change
2015-02-08 15:31 rockn New Issue
2015-02-08 16:18 yorik Summary Set colors don't work on object where edit mode is modified. => Set colors doesn't work on objects that have edit mode reimplemented
2015-02-08 16:18 yorik Description Updated View Revisions
2016-01-19 01:55 yorik Target Version 0.16 =>
2016-01-20 14:00 jmaustpc Note Added: 0006736
2016-01-20 14:01 jmaustpc Note Edited: 0006736 View Revisions
2016-01-31 18:15 yorik Note Added: 0006780
2017-01-17 20:01 Kunda1 Note Added: 0007849
2017-01-19 12:20 wmayer Relationship added related to 0000477
2017-01-19 13:04 wmayer Note Added: 0007874
2017-01-19 13:05 wmayer Assigned To => wmayer
2017-01-19 13:05 wmayer Status new => assigned
2017-06-07 21:11 Kunda1 Tag Attached: colors
2017-10-02 04:42 Kunda1 Note Added: 0010236
2019-02-24 18:30 wmayer Target Version => 0.19