My free software activities in December 2018

[kkremitzki]

My November 2018 summary is up, along with a list of my Debian packaging TODOs: https://kkremitzki.github.io/blog/free- ... mber-2018/

[kkremitzki]

My December summary: https://kkremitzki.github.io/blog/free- ... mber-2018/

[kkremitzki]

My January & February summaries: https://kkremitzki.github.io/blog/my-fr ... uary-2019/

[Joel_graff]

My January & February summaries: https://kkremitzki.github.io/blog/my-fr ... uary-2019/

Thanks for the update, Kurt. I really enjoy reading them.

I had a question on the issue of distributing FCStd files and the Debian guidelines...

I'm assuming the Debian issue is that a zip is a 'binary' format, even though the content within is entirely plain text xml and the like. But is the issue caused by using any compression at all, or just using ZIP? I noticed elsewhere the Debian guidelines seem to prefer tar.gz over zip, but given that the ZIP format is, itself, public domain, I'm not sure I see why it would matter.

If another compression format would be acceptable for redistribution under Debian, have we considered migrating FCStd to it?

[kkremitzki]

Well the contents of the files vary, they're XML and then some, there are still binary objects in there if you unzip some of the examples and take a look.

[Joel_graff]

Well the contents of the files vary, they're XML and then some, there are still binary objects in there if you unzip some of the examples and take a look.

Gotcha. I remembered seeing brp and xml, but forgot about array files ... and thumbnails, I guess. I suppose the question is, is it worth trying to make FCStd's compliant for redistribution?

[kkremitzki]

Gotcha. I remembered seeing brp and xml, but forgot about array files ... and thumbnails, I guess. I suppose the question is, is it worth trying to make FCStd's compliant for redistribution?

It should be possible. All the binary files have their types defined in the XML files, and the specifications for those types are as open and clear as the FreeCAD source code that defines them, so there's not really any mystery about a .FCStd file... my hope is that since my blog is syndicated to Planet Debian, someone might see it and say something. If not I can also start asking.

Even if we can start shipping the examples, it would also be nice if possible to macro-record their creation where feasible and ship those with the examples.

[NormandC]

I've tested macro recording the other night, I created a PartDesign Body with 3 features (a pad, a pocket and a fillet). The odd thing is, it records every step, but it comments out the GUI operations. The result is, when you launch the macro to recreate the model, all three features are visible at the same time, when a Body should only show one at a time, the one defined as tip.

If I end up doing one or two macros, I'll need help to fix that, because I am clueless at Python.

All the binary files have their types defined in the XML files, and the specifications for those types are as open and clear as the FreeCAD source code that defines them, so there's not really any mystery about a .FCStd file...

Come to think of it, it's the same thing for STEP, isn't it? Even more so, as STEP is just plain text. Does Debian consider it OK to distribute STEP files?

IMO we should still try to provide scripts for the example files, even if Debian is a very specific and marginal case in view of the FreeCAD users at large. Besides, it cannot hurt to show that those example files can be scripted, which might be useful for end users.

But I think not all example files are worthy of getting scripted, or even of being kept in binary format. I'm thinking of the EngineBlock which is 6-year old and no longer represents what FreeCAD can do. Just look at any miniature steam engine posted in the Users showcase! Then there's the DrawingExample, based on the outdated Drawing wb.