FreeCADView Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001963 | FreeCAD | Bug | public | 2015-02-11 23:57 | 2017-01-17 20:02 |
| Reporter | triplus | Assigned To | wmayer | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Platform | Linux | OS | Ubuntu | OS Version | 14.04 |
| Fixed in Version | 0.16 | ||||
| Summary | 0001963: Only write needed user data in FCSTD file if any. | ||||
| Description | In 99% of the time this is a non issue but still i don't believe it's a good policy to write user data in FCSTD file. I found two recording but there could be more: Inside Document.xml: At the beginning of file: <Property name="FileName" type="App::PropertyString"> <String value="USER DATA"/> </Property> Property for Drawing WB Drawing Page: <Property name="Template" type="App::PropertyFile"> <String value="USER DATA"/> </Property> I opened FCSTD file today with some drawings in it. This file was not made by me and i noticed Page object Template property had original user Template location in it. This values in my opinion should not persist and should be replaced by defaults when FreeCAD restarts. Therefore they should not be written to FCSTD file at all. Cheers! | ||||
| Tags | No tags attached. | ||||
| FreeCAD Information | |||||
| related to | 0001910 | closed | Drawing | Add a preference page for the Drawing workbench and allow to select a folder for custom templates | |
| related to | 0002064 | closed | wmayer | Drawing | Editable text changes in drawing template not restored. |
| related to | 0002224 | closed | Drawing | Drawings break on reopen. Template not found | |
| related to | 0002184 | closed | Drawing | Drawing template filenames for ISO7200 are numbered consecutively but corresponding files do not exist |
|
|
Not storing the Drawing::Page Template (and, for that matter, any other template) property is problematic. If you use a specific template of your own, that is not in the FreeCAD data folder, that value is lost on restoring the file, and the Drawing Page doesn't render anymore (can't find its template). I'd vote for reverting this change, unless someone has a better idea? |
|
|
I am not sure it worked that way as i opened the file from another user and he made that file on Windows OS. I opened it on Ubuntu OS. The drawing was opened correctly as it was stored in the .fcstd file itself? The path revealed quite a lot of information of that user and his current project and that info had none useful value for my OS. The drawing template is stored in .fcstd file as part of the file itself? Anything essential to render Drawing Page correctly after the Drawing Page is created should be stored in .fcstd file itself? Or did i misunderstand something? |
|
|
> Not storing the Drawing::Page Template (and, for that matter, any other template) property is problematic. Is this only a theoretical consideration that it doesn't work or do you have a real example? I don't see a problem because "Template" is a PropertyFile (which is actually only a PropertyString). When you set it to an arbitrary file then the FeaturePage copies its content to the "PageResult" property. The Template stores an absolute path and it's of absolute no use for anybody else loading your project file because he might not have this (custom) template. Even for built-in templates it might be useless if FreeCAD is installed into a different directory. And last but not least, even for you it's of almost no use because you cannot do anything with the Template property but changing to another file because in this case the "PageResult" will be updated again. The fix of this commit doesn't only fix triplus' concern but makes the Template property more platform-independent now because the its full path is created from the resource directory and the file name of 'PageResult'. |
|
|
Actually i made one test as i am working on DXF templates. SVG + DXF template with the same names need to be at the same location at export time. I have the templates in custom location ATM and export to DXF works just fine. At least until FreeCAD is restarted. I didn’t test the behaviour if the templates are at FreeCAD default location. This is i guess one use case where after FreeCAD restart and document restore DXF export will not work as expected. BUT at the same time i must say it would only work on the same PC in the first place if original path to SVG drawing template would be preserved. Only real solution for cases like this would be to save corresponding DXF template inside .fcstd file for later use (on any PC by any user). |
|
|
If SVG drawing template is loaded from default location (i guess resource directory) exporting of DXF templates works just fine after FreeCAD restarts. If SVG drawing template is loaded from custom location exporting of DXF templates stops working as expected as soon as FreeCAD is restarted. I guess because of original SVG drawing template directory information is lost. In my opinion in both cases DXF drawing template from default or custom location should be written to .fcstd file because we have to assume, SVG/DXF drawing templates evolve over time regardless of default name in resource directory at any given time. Just my opinion based on one example (drawing templates). |
|
|
It is true that if the absolute template path is stored, opening the file on another computer fails. But for one's personal use, it was useful... I have all my personal templates in a separate folder that is not in the FreeCAD tree, and now everytime I open a project that uses one of these templates, I cannot modify the drawing pages anymore because it fails to recompute. But okay, if the majority of you thinks this is better, I'll deal with it. Maybe we could at least search for templates in the user's freecad dir too? Maybe in userAppData/Templates? I can try to implement that... |
|
|
"Maybe we could at least search for templates in the user's freecad dir too? Maybe in userAppData/Templates? I can try to implement that..." It would be nice to have this possibility: http://www.freecadweb.org/tracker/view.php?id=1910 "I cannot modify the drawing pages anymore because it fails to recompute." I would count that as bug and from .fcstd integrity point of view the strategy should probably be to always include everything needed inside the .fcstd file itself. To be able to restore the project on different location. There was similar discussion for assemblies in the past and to store or not to store online parts in the.fcstd itself. When you don't store everything needed to preserve integrity of .fcstd itself inside .fcstd itself then you get situations like this. And drawing templates for example evolve and there is little chance drawing template named A4_Landscape available by default in FC 15 and FC 20 will be the same. Relying to this will bring only breakage in the future. |
|
|
I think it won't be always possible to embed everything inside the fcstd file, in the future there might be textures and things like that, that might make the file size explode... Anyway, okay for this one, but I still think that something that worked before and that doesn't work anymore is a bug. |
|
|
Yes there is dilemma of file size i know. BUT should file size explode or should the file itself explode if "ported" and opened on different computer. In the end i believe the file size should be as big as it needs to be to maintain integrity. About the bug aspect i would agree the behaviour is not something the user will not see as a bug but probably it is not just about the bug but it involves the question what is the best strategy/policy on the long run. This sort of things usually need a bit more effort to achieve. For example if custom location for drawing templates will be implemented it will be great. But integrity of .fcstd file itself will not become 100% as default drawing templates will evolve over time and on another PC there will be no custom location with the same set of drawing templates available... |
|
|
Anyway this will continue to be a problem if user A has a template that user B doesn't have. Now both users have the problem :) But no need to argue forever over this. If you guys are happy with the latest change, for me it's okay too |
|
|
- I do believe it is a good policy not to write user data in FCSTD file. - I do believe it is a good policy to write everything that is needed to preserve .fcstd integrity in .fcstd file itself. Beyond stating that i agree no need to argue any more and will use FreeCAD as it comes. :) |
|
|
Ok reading this again: "its full path is created from the resource directory and the file name of 'PageResult'" I am quite sure as the result we produced this bug: http://www.freecadweb.org/tracker/view.php?id=2064 Question: Why does it make sense for SVG drawing template always to be re-loaded from FreeCAD template location on opening .fcstd file? Instead of loading it only once and as it's saved inside .fcstd file simply open it again from inside .fcstd file? I am guessing that does not require any user data to be written inside .fcstd file itself or reduce "portability" as FreeCAD will know where the file is located (opened from)? P.S. But i must say this demonstrated how always loading drawing template can "explode file" and demonstrates why it makes sense to rather "explode file size" and preserve .fcstd integrity. :) |
|
|
But indeed if original SVG drawing template location is inside .fcstd file corresponding DXF drawing template should be at the same location (inside .fcstd) or the DXF drawing template will not be exported? That would be a shame. Or to sacrifice editable text support just to get predictable results with limiting support to default set of drawing templates that always get re-loaded. Actually for me if doable (SVG + DXF drawing templates inside .fcstd file) this is good idea as having custom drawing templates won't affect portability and editable text support would be possible again. And no user data needs to be written inside .fcstd file to make that work? Thinking ahead: There is a good chance FreeCAD DW will get GUI SVG editing capabilities in the future and all modifications and changes will be saved in SVG file (saved inside .fcstd file) therefore the strategy to reload default drawing template each time .fcstd file is opened won't do. As said if by any chance there is motivation it would be great to enable saving corresponding (file name) DXF drawing template (if the template exists) to .fcstd file to always be available for DXF export regardless of the set of drawing templates available on the user system! |
|
|
There is one more issue i found. After inserting the drawing template you can change it with Page Template Property. Doing that will change the template in drawing view but after save and reopen file operation the one that was inserter originally will be loaded again. This is not about changing the template with custom one but about using another one from resource directory. |
|
|
> It is true that if the absolute template path is stored, opening the file on another computer fails. At least when you open a project under Windows which created under Linux the template path won't work. > Yes there is dilemma of file size i know. BUT should file size explode or should the file itself explode if "ported" and opened on different computer. Putting always everything inside a project doesn't make sense. There are scenarios where this should be avoided. I have use cases where I get an amount of data that easily reaches 1GB. > - I do believe it is a good policy not to write user data in FCSTD file. I agree. > - I do believe it is a good policy to write everything that is needed to preserve .fcstd integrity in .fcstd file itself. I do not agree. > Base::FileInfo tempfi(App::Application::getUserAppDataDir() + "Templates/" + fi.fileName()); Shouldn't we make an extra sub-directory "Drawing", i.e. Drawing/Templates? Now we have one Template directory where it is assumed to have .svg, pov and .lux templates together. Then we could change the property editor of PropertyFile to only list the available templates. |
|
|
"Putting always everything inside a project doesn't make sense. There are scenarios where this should be avoided. I have use cases where I get an amount of data that easily reaches 1GB." True. 1GB sounds terrible BUT: 1.) Majority of use cases won't fill 1% in the end. 2.) If you use features that need this much data you will end up with 1GB data stored somewhere anyway. If in some use cases 1GB is needed to preserve .fcstd integrity fine 1GB it is. For example storing SVG + DXF drawing template inside .fcstd file gives you what (for few additional KBs): - Drawing template always shown correctly as it was inserted with all modifications made by the user included. - DXF export with (modified) drawing template will always work as intended. Regardless of the location .fcstd was opened and regardless of the fact if user has original drawing templates you used available. Alternative is currently broken editable text capabilities and quite possible future results where drawing template won't be the same as originally inserted. No support for inserting custom SVG/DXF template in the file and viewing that on different location... Stuff like templates where is all text data and compressible and we are talking about few KBs more or less... And alternative is full of sorrow... Just do it! |
|
|
For example what is alternative ATM if you create project and some drawings in it. You want to share that with somebody else. - You need to create and save the file. - Create a copy and manually edit SVG template in Inkscape. - Write manual on how the end user should deal with the modified template (location to be moved on destination computer). - Compress everything into single package and send e-mail. And as i forgot about supplementary DXF drawing template therefore the need to repeat the procedure is here. :) Anyway as i won't code the end solution my task ends here but hopefully the situation in this area will improve in the future. |
|
|
> Shouldn't we make an extra sub-directory "Drawing", i.e. Drawing/Templates? > Now we have one Template directory where it is assumed to have .svg, pov and > .lux templates together. Maybe... I thought the user won't have tons of these templates, so it might actually be easier to have a simple structure inside his .FreeCAD folder (Mods, Materials, Templates, etc). But I have no strong opinion there... |
|
|
OK, then leave it this for now. In case there will be too many files we still can make sub-directories. |
|
|
OK i did some tests today and want to get this clear: "Search for templates in userAppData/Templates folder" What does this actually do or should do? My assumption was it looks inside: UserAppDataDir/Templates (.FreeCAD/Templates on Linux) and if it finds any drawing or raytracing templates it will list them in appropriate drop-down list? Was my assumption wrong as based on my tests nothing specific happens when putting drawing template in UserAppDataDir/Templates. |
|
|
OK i connected the dots: http://forum.freecadweb.org/viewtopic.php?f=8&t=10929&p=88005#p88005 Honestly speaking, current behaviour regarding drawing templates, where FreeCAD does write drawing template inside .fcstd file but after that doesn't use it any more regardless of availability of drawing templates on any given PC where FreeCAD is installed is in my opinion inherently broken. If this is how it should be done fine but this will "blow up" again and again and i lack motivation to report bugs or think about this any further as it's broken by design and just can't work reliably until changed. There is no reliable way to use custom templates without much hassle for end users and current drawing templates would need to stay intact indefinitely. If there will be other areas in the future where devs will choose the same path at least consider doing a tool like "FCSTD Migrator" where user can migrate the .fcstd file to different PC and the file won't "blow up" as "FCSTD Migrator" will do what is necessary. For example in this case copy provided drawing template inside userAppData/Templates folder before opening .fcstd file. |
|
|
If we have possibility to store custom drawing templates in userAppData/Templates folder i would expect custom drawing templates inside userAppData/Templates folder would show up in drawing workbench drop-down menu. If devs disagree feel free to close this issue report. Cheers. |
|
|
Additional issue introduced by the new behavior: http://forum.freecadweb.org/viewtopic.php?f=3&t=11655 If user uses the same drawing template multiple times in the same document only one Page will end up with working drawing template in the end. For example using A4_Landscape_plain.svg drawing template 3 times will add this inside .fcstd file: A4_Landscape_plain.svg A4_Landscape_plain1.svg A4_Landscape_plain2.svg But when this file will be opened again FreeCAD will only find A4_Landscape_plain.svg drawing template in default drawing template folder. It won't find A4_Landscape_plain1.svg and A4_Landscape_plain2.svg drawing templates. I know we don't agree on this but drawing templates belong in .fcstd file and after they are added FreeCAD should use them directly from .fcstd file. The same for DXF counterparts. Everything else simply can't work reliably and produces unexpected results now or in the future when default set of drawing templates changes. |
|
FreeCAD: master 8476bab7 2015-04-11 22:30:11 Details Diff |
+ fixes 0001963: Only write needed user data in FCSTD file if any. |
Affected Issues 0001963 |
|
| mod - src/Mod/Drawing/App/FeaturePage.cpp | Diff File | ||
| mod - src/Mod/Drawing/App/FeaturePage.h | Diff File | ||
| mod - src/Mod/Raytracing/App/LuxProject.cpp | Diff File | ||
| mod - src/Mod/Raytracing/App/LuxProject.h | Diff File | ||
| mod - src/Mod/Raytracing/App/RayProject.cpp | Diff File | ||
| mod - src/Mod/Raytracing/App/RayProject.h | Diff File | ||
|
FreeCAD: master 01480a17 2015-04-20 17:45:43 Details Diff |
Workaround for issue 0001963 - Search for templates in userAppData/Templates folder |
Affected Issues 0001963 |
|
| mod - src/Mod/Drawing/App/FeaturePage.cpp | Diff File | ||
| mod - src/Mod/Raytracing/App/LuxProject.cpp | Diff File | ||
| mod - src/Mod/Raytracing/App/RayProject.cpp | Diff File | ||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2015-02-11 23:57 | triplus | New Issue | |
| 2015-04-11 20:41 | wmayer | Changeset attached | => FreeCAD Master master 8476bab7 |
| 2015-04-11 20:41 | wmayer | Assigned To | => wmayer |
| 2015-04-11 20:41 | wmayer | Status | new => closed |
| 2015-04-11 20:41 | wmayer | Resolution | open => fixed |
| 2015-04-19 21:46 | yorik | Note Added: 0006053 | |
| 2015-04-19 21:47 | yorik | Status | closed => feedback |
| 2015-04-19 21:47 | yorik | Resolution | fixed => reopened |
| 2015-04-19 22:23 | triplus | Note Added: 0006055 | |
| 2015-04-19 22:23 | triplus | Status | feedback => assigned |
| 2015-04-19 22:46 | wmayer | Note Added: 0006056 | |
| 2015-04-19 23:26 | triplus | Note Added: 0006057 | |
| 2015-04-19 23:59 | triplus | Note Added: 0006058 | |
| 2015-04-20 14:53 | yorik | Note Added: 0006059 | |
| 2015-04-20 15:14 | triplus | Note Added: 0006061 | |
| 2015-04-20 15:16 | triplus | Note Edited: 0006061 | |
| 2015-04-20 15:19 | yorik | Relationship added | related to 0001910 |
| 2015-04-20 15:23 | yorik | Note Added: 0006063 | |
| 2015-04-20 15:51 | yorik | Changeset attached | => FreeCAD Master master 01480a17 |
| 2015-04-20 16:02 | triplus | Note Added: 0006064 | |
| 2015-04-20 17:23 | yorik | Note Added: 0006065 | |
| 2015-04-20 17:37 | triplus | Note Added: 0006066 | |
| 2015-04-21 00:21 | triplus | Note Added: 0006067 | |
| 2015-04-21 00:22 | triplus | Note Edited: 0006067 | |
| 2015-04-21 00:48 | triplus | Note Added: 0006068 | |
| 2015-04-21 00:50 | triplus | Note Edited: 0006068 | |
| 2015-04-21 01:05 | triplus | Note Edited: 0006068 | |
| 2015-04-21 01:06 | triplus | Note Edited: 0006068 | |
| 2015-04-21 15:26 | triplus | Note Added: 0006069 | |
| 2015-04-21 19:30 | wmayer | Note Added: 0006070 | |
| 2015-04-21 21:22 | triplus | Note Added: 0006073 | |
| 2015-04-21 22:04 | triplus | Note Added: 0006074 | |
| 2015-04-22 22:06 | yorik | Note Added: 0006075 | |
| 2015-04-24 12:29 | wmayer | Note Added: 0006082 | |
| 2015-04-24 12:29 | wmayer | Status | assigned => closed |
| 2015-04-24 12:29 | wmayer | Resolution | reopened => fixed |
| 2015-04-24 12:29 | wmayer | Fixed in Version | => 0.16 |
| 2015-04-25 00:12 | ian.rees | Relationship added | related to 0002064 |
| 2015-05-13 12:16 | triplus | Note Added: 0006130 | |
| 2015-05-13 12:16 | triplus | Status | closed => feedback |
| 2015-05-13 12:16 | triplus | Resolution | fixed => reopened |
| 2015-05-14 09:35 | triplus | Note Added: 0006133 | |
| 2015-05-14 09:35 | triplus | Status | feedback => assigned |
| 2015-05-14 09:55 | triplus | Note Edited: 0006133 | |
| 2015-05-14 09:56 | triplus | Note Edited: 0006133 | |
| 2015-05-14 12:55 | triplus | Note Added: 0006134 | |
| 2015-07-05 17:57 | triplus | Note Added: 0006243 | |
| 2015-07-05 18:02 | triplus | Note Edited: 0006243 | |
| 2015-08-20 14:00 | yorik | Relationship added | related to 0002224 |
| 2016-05-05 09:14 | wmayer | Status | assigned => closed |
| 2016-05-05 09:14 | wmayer | Resolution | reopened => fixed |
| 2017-01-17 20:02 | Kunda1 | Relationship added | related to 0002184 |
