View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002276||FreeCAD||Feature||public||2015-09-25 09:38||2016-01-19 02:06|
|Fixed in Version||0.16|
Would it be possible to either:
a) add a Drawing::PythonFeatureView, which would be an extension of the Drawing::FeatureView base class,
with support for adding properties and using proxies, or
b) modify FreeCAD_sf_master/src/Mod/Drawing/App/FeaturePage.cpp: App::DocumentObjectExecReturn:
to load contents from ViewResult property from objects in the pages group (relax the isDerivedFrom(Drawing::FeatureView::getClassTypeId() restriction)
Either of these changes would greatly facilitate the development parametric functionality in the drawing dimensioning workbench.
|Tags||No tags attached.|
||There is one already, called Drawing::FeatureViewPython|
||b) is a good idea, I've been meaning to do that some time ago and forgot.|
Wow, i can't believe i never new about the Drawing::FeatureViewPython.
Feeling sheepish now:)
Forget about b) the Drawing::FeatureViewPython object looks like it can do everything i need it to for my purposes.
Please close the issue.
||I'll implement b) anyway when I have a minute... It would be useful to have anyway.|
Played around with the Drawing::FeatureViewPython a little.
I am encountering difficulty with the default view provider for Drawing::FeatureViewPython objects.
AttributeError: 'Gui.ViewProviderDocumentObject' object has no attribute 'addProperty'
AttributeError: 'Gui.ViewProviderDocumentObject' object has no attribute 'Proxy'
Perhaps, persueing option b) would be better:
A user could then add a App::FeaturePython under the page group with a ViewResult property whose contents will be loaded into the drawing page.
That way the ViewProviderPythonFeature functionality which does not suffer from 1) and 2) can be leveraged...
Another thought regarding b):
how about modifying FreeCAD_sf_master/src/Mod/Drawing/App/FeaturePage.cpp: App::DocumentObjectExecReturn:
to load contents from both
* the ViewResult property from objects DerivedFrom(Drawing::FeatureView::getClassTypeId())
* objects which have a DrawingPageViewResult property.
Where a verbose property name like `DrawingPageViewResult` would almost entirely eliminate the chances of a user accidentally using a property with name for another purpose...
Indeed as far as I know the view provider of the Drawing::FeatureViewPython doesn't have a python version, it uses the defautl C++ one. Since the drawingview object doesn generate anything in the 3D view, I suppose nobody needed it...
But indeed it could be nice so someone could change the icon and claim children from python code...
FreeCAD: master 3bbddc86
2015-12-23 20:03:46Details Diff
|Drawing: Added python feature to ViewProviderDrawingView - fixes 0002276||
|mod - src/Mod/Drawing/App/FeatureView.cpp||Diff File|
|mod - src/Mod/Drawing/Gui/AppDrawingGui.cpp||Diff File|
|mod - src/Mod/Drawing/Gui/ViewProviderView.cpp||Diff File|
|mod - src/Mod/Drawing/Gui/ViewProviderView.h||Diff File|
|2015-09-25 09:38||hamish2014||New Issue|
|2015-09-25 14:22||yorik||Note Added: 0006447|
|2015-09-25 14:23||yorik||Note Added: 0006448|
|2015-09-25 14:23||yorik||Assigned To||=> yorik|
|2015-09-25 14:23||yorik||Status||new => assigned|
|2015-09-25 14:54||hamish2014||Note Added: 0006449|
|2015-09-25 14:56||yorik||Note Added: 0006450|
|2015-09-26 05:33||hamish2014||Note Added: 0006459|
|2015-09-26 05:52||hamish2014||Note Added: 0006460|
|2015-09-26 15:06||yorik||Note Added: 0006464|
|2015-12-23 19:04||yorik||Changeset attached||=> FreeCAD Master master 3bbddc86|
|2015-12-23 19:04||yorik||Status||assigned => closed|
|2015-12-23 19:04||yorik||Resolution||open => fixed|
|2016-01-19 02:06||yorik||Fixed in Version||=> 0.16|