View Issue Details

IDProjectCategoryView StatusLast Update
0001963FreeCADBugpublic2017-01-17 20:02
Reportertriplus Assigned Towmayer  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSUbuntuOS Version14.04
Fixed in Version0.16 
Summary0001963: Only write needed user data in FCSTD file if any.
DescriptionIn 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!
TagsNo tags attached.
FreeCAD Information

Relationships

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 closedwmayer 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 

Activities

yorik

2015-04-19 21:46

administrator   ~0006053

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?

triplus

2015-04-19 22:23

developer   ~0006055

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?

wmayer

2015-04-19 22:46

administrator   ~0006056

> 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'.

triplus

2015-04-19 23:26

developer   ~0006057

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

triplus

2015-04-19 23:59

developer   ~0006058

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

yorik

2015-04-20 14:53

administrator   ~0006059

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...

triplus

2015-04-20 15:14

developer   ~0006061

Last edited: 2015-04-20 15:16

"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.

yorik

2015-04-20 15:23

administrator   ~0006063

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.

triplus

2015-04-20 16:02

developer   ~0006064

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...

yorik

2015-04-20 17:23

administrator   ~0006065

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

triplus

2015-04-20 17:37

developer   ~0006066

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

triplus

2015-04-21 00:21

developer   ~0006067

Last edited: 2015-04-21 00:22

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

triplus

2015-04-21 00:48

developer   ~0006068

Last edited: 2015-04-21 01:06

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!

triplus

2015-04-21 15:26

developer   ~0006069

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.

wmayer

2015-04-21 19:30

administrator   ~0006070

> 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.

triplus

2015-04-21 21:22

developer   ~0006073

"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!

triplus

2015-04-21 22:04

developer   ~0006074

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.

yorik

2015-04-22 22:06

administrator   ~0006075

> 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...

wmayer

2015-04-24 12:29

administrator   ~0006082

OK, then leave it this for now. In case there will be too many files we still can make sub-directories.

triplus

2015-05-13 12:16

developer   ~0006130

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.

triplus

2015-05-14 09:35

developer   ~0006133

Last edited: 2015-05-14 09:56

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.

triplus

2015-05-14 12:55

developer   ~0006134

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.

triplus

2015-07-05 17:57

developer   ~0006243

Last edited: 2015-07-05 18:02

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.

Related Changesets

FreeCAD: master 8476bab7

2015-04-11 22:30:11

wmayer

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

yorik

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

Issue History

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