FreeCADView Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000740 | FreeCAD | Bug | public | 2012-06-07 07:47 | 2012-06-09 13:31 |
| Reporter | jmaustpc | Assigned To | |||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | all | OS | all | OS Version | all |
| Fixed in Version | 0.13 | ||||
| Summary | 0000740: work bench initiation from in fcstd file | ||||
| Description | For projects that utilise Draft, Arch, and presumably all Python work benches the fcstd file requires the appropriate Python work bench be initiated before the file is opened, otherwise it doesn't display the Python items in the tree properly. | ||||
| Steps To Reproduce | create anything in Draft and/or Arch Work Benches, save the file close FreeCAD. Start FreeCAD again then just open the file again immediately without opening the appropriate workbench. | ||||
| Additional Information | I know there is a security issue with allowing Python code to be stored and run from the fcstd file, as Juergen and others have previously discussed. But I wonder if this below makes sense. 1) list in the fcstd file a list of "work bench dependencies" for that specific fcstd file. 2) have FreeCAD on "open file" first read this list of dependencies and initialise the appropriate work benches? Definitely not any arbitrary code, just only allow initiation of workbenches that the FreeCAD program already knows it contains? If implemented correctly I don't think it would be a security risk, because all the file is saying is open that pre-existing workbench. Any "bad" code would have to already be in that workbench as part of the FreeCAD application code because all that is transferred from the fcstd file is a text name of a workbench, not any code. I don't know enough to make a serious detailed proposal but doesn't this make sense? If the "work bench dependency" is just a list of text in the fcstd file then the FreeCAD application would contain all the code to do anything with that data, so it would not matter what the text said, if it did not match a known FreeCAD workbench name then FreeCAD would not execute anything. Presumably the compiled FreeCAD application would contain a list of work bench names in text to compare with those found in the fcstd file, if FreeCAD application finds a match, then it would follow instructions already pre-coded into the FreeCAD application code to initiate the appropriate work benches. | ||||
| Tags | No tags attached. | ||||
| FreeCAD Information | |||||
|
2012-06-07 07:47
|
|
|
|
But this information is/should be allready in the FcStd file. The (c)Pickle Module saves it for every FeaturePython Proxy. Maybe I'm confusing Module and Workbench. |
|
|
To load a object its only needed to load the module, the WB need not to be activated. If python objects are not loaded without the module pre-loaded its cleary a bug. |
|
|
As far as I can tell there is no problem... This works without problem: 1) make sure the default WB is not Draft 2) switch to Draft, draw something 3) save the file 4) close and reopen FreeCAD, default WB is StartWB 5) open the saved file Probably it's your file that has some problem... Looking at your screenshot, looks like the Arch module didn't init correctly, probably because of the bug we talked about in the forum today.. |
|
|
The (c)Pickle module assures that the python module is loaded where the python class is part of. So, when checking a project with an Arch wall you can clearly see in the debugger that the object is properly instantiated. But the problem that the wrong icon is shown has nothing to do with (c)Pickle. The problem is quite simple: _ViewProviderWall returns a path to a Qt resource file ":/icons/Arch_Wall_Tree.svg" This file, however, is not known as long as the Arch resource file is not loaded. And this resource file gets loaded together with the loading of the Arch module. |
|
|
git show 0bf33b6 The bug was fixed by explicitly doing an "import Arch_rc" in the getIcon() method of the python view provider classes. |
|
|
ah indeed, thanks for the fix Werner! Later on I should simplify that by making all Arch objects derived from a same base class... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-06-07 07:47 | jmaustpc | New Issue | |
| 2012-06-07 07:47 | jmaustpc | File Added: python_wb_required_before_file_open.jpg | |
| 2012-06-07 08:46 | shoogen | Note Added: 0002141 | |
| 2012-06-07 10:01 |
|
Note Added: 0002142 | |
| 2012-06-07 12:13 | yorik | Note Added: 0002143 | |
| 2012-06-09 07:40 | wmayer | Note Added: 0002163 | |
| 2012-06-09 07:51 | wmayer | Note Added: 0002164 | |
| 2012-06-09 07:51 | wmayer | Status | new => closed |
| 2012-06-09 07:51 | wmayer | Resolution | open => fixed |
| 2012-06-09 07:51 | wmayer | Fixed in Version | => 0.13 |
| 2012-06-09 13:31 | yorik | Note Added: 0002167 |
