Talk:OSE Collaboration Protocol - Revision history

Andrewusu: Moving to separate page

2021-12-12T11:21:09Z

Moving to separate page

← Older revision		Revision as of 11:21, 12 December 2021
Line 1:		Line 1:
	~~==Andrewusu's thoughts on FreeCAD git integration==~~

	~~===FreeCAD v0.17 and newer===~~
	~~As of FreeCAD version 0.17 the [https://wiki.freecadweb.org/WebTools_Git WebTools Workbench] allows Git integration through manual steps.~~

	~~However *.fcstd files are binary files, specifically zip archives, and binary files aren't really suitable for version control tools like Git.~~

	~~To prevent the explosion in space usage this mal-use would cause, a git filter should be set up for these *.fcstd files, such as:~~
	~~# [https://git.opensourceecology.de/hoijui/ReZipDoc hoijui/ReZipDoc] Open Source Ecology Germany, requires JRE 8 or newer [https://stackoverflow.com/a/54925238/1185900 writeup]~~
	~~# [https://github.com/callegar/Rezip callegar/Rezip], written in bash, won't work on Windows (unless cygwin is used). Might have unwanted permissions changes on files due to the rezip?~~
	~~# [https://bitbucket.org/sippey/zippey Zippey], written in python. Zippey uses a different strategy than the other two so isn't compatible with them.~~

	The rezip tools essentially re-zip the zip archive with a compression of 0, to allow git to compress better given changes through time. While Zippy is a bit different than the rezip tools... I'm not sure at a glance the implications of using it.

	If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes. I expect any user can use either they want, as long as they have the global git config filter set up for the tool they have, and that filter name matches what is in the repo's .gitattributes

	If a user hadn't properly set up a rezip tool and pushes their changes, then there won't be any problems other than a size increase. Which I suppose can be manually fixed later, but that is a headache.

	~~To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.~~

	However, FreeCAD in a future version will support better integration with version control without such re-zip workarounds and additional workflow steps (e.g. FreeCAD automatically controlling git after a save instead of the user controlling git after saving the file).

	~~===FreeCAD v0.18 and newer (or v0.19 and newer?)===~~
	[[File:FreeCAD_assembly3_document_links.png\|thumb\|Brief view of Assembly3 assembly, document, and link organization. Sub-assemblies which are linked to an external document, will result in that external document being loaded and displayed as shown. While frozen they won't consume much memory.]]

	Has realthunder's Assembly3 workbench. Supports links, which help eliminate prior memory limitations with larger assemblies, and need for such workarounds like [[File_Simplification]]. So long as the linked document is opened and the link is frozen, the assembly is displayed within the parent document as a single unmodifiable geometry. When the linked document is closed it won't be displayed anymore in the parent document.

	~~I think it would be best if when the Assembly3 workbench isn't active,~~
	~~[[File:FreeCAD_assembly3_workbench.png]]~~

	~~That a simplified view of the model is presented in the Combo view, without the '''Constraints, Elements, Parts''' and additional hierarchy that Assembly3 at present introduces to FreeCAD:~~
	~~[[File:FreeCAD_simple_hiearichy.png]]~~

	The clutter of external documents in the tree view can be hidden by the setting 'View -> TreeView actions -> Single document'. But I'm still looking for a way to hide the Constraints, Elements, Parts containers- which would entail changing the TreeView to use a proper model-view separation. This change would also allow the ability to reorder items easily in the TreeView, something others would like to see implemented anyway.

	~~===FreeCAD v0.20 and newer===~~
	realthunder [https://forum.freecadweb.org/viewtopic.php?f=10&t=38353 has made changes in FreeCAD to better support Version Control], however he writes [https://forum.freecadweb.org/viewtopic.php?f=10&t=38353&start=20#p379536 "It is still in my fork. I think this feature will most likely land in the next 0.20 release"].

	~~[[File:FreeCAD_realthunder_save_as_directory.png\|thumb\|Save as directory for version control integration in FreeCAD v0.20 and newer and realthunder's fork]]~~

	~~realthunder has put in the plumbing to allow an FreeCAD module to automatically manage the version control of the CAD files.~~

	~~====My envisioned solution====~~
	~~While the solution with the FreeCAD WebTools Workbench and rezip should work... better possibilities exist, which will:~~
	~~# Better handle multiple documents, allowing re-use of work done (why invent the wheel twice!)~~
	## Each linked sub-assembly of a parent assembly will have their own document, in their own git branch, with their own history, allowing other assemblies to make use of and update that subassembly without changing the original parent assembly.
	~~# Transparent git integration~~
	~~## End-user does not have to interact with git or do any additional steps, other than save and enter a commit message~~
	~~# Module will notify user of any update to a document they're working on~~

	~~Use FreeCAD v0.20 once available, or realthunder's present fork.~~

	~~Set up a Module to respond to the signals. The signal data will include what files were modified/deleted/added. The module will:~~
	~~# Interact with git. e.g. Commit the changes to a new revision.~~
	~~# Push the new commit to a remote repository, if a remote repository is designated in the document properties.~~
	~~# Put sub-assemblies into their own branch, and use git sub-repo to include those sub-assemblies in a subdirectory in the main branch (likely master).~~
	~~# If a remote repository was designated for any sub-assembly, the module will push any change for that sub-assembly to that sub-assembly.~~

	~~In addition to the module:~~
	~~# Add a means of adding properties to the document, so that the FreeCAD user can use the GUI to designate a remote version control repository to push/pull the changes to.~~
	~~# Add a means for the user to enter a commit message when they save the document.~~

	~~====Annotated Visual History====~~
	~~I'm not sure what would be the most optimal way to implement [[Annotated_Visual_History]].~~

	~~A simple idea would be to have:~~
	~~# An ".annotated_visual_history_cache" folder, which is listed in .gitignore (not versioned)~~
	~~# FreeCAD on opening a version controlled directory without, to interact with the module as the module iterates through git revisions, to cache each revision.~~
	~~# On each revision, take a set of isometric snapshots rotating around the assembly, resized to say 64x64 px.~~
	~~## The module can possibly iterate through each revision [https://wiki.freecadweb.org/Embedding_FreeCADGui#Without_even_firing_up_the_FreeCAD_Gui without opening up the FreeCAD GUI].~~
	# An image processing utility will assign a complexity score to each snapshot, and the snapshot with the maximal complexity score will be selected as the thumbnail. A complexity score being a proxy measure of what image best illustrates the part!
	~~## Filesize might suffice as an indirect measurement of complexity, the largest image being the most complex, otherwise,~~
	~~## ImageMagick's identify might suffice, with a grep of a -verbose output, or a [https://imagemagick.org/script/command-line-options.php#features -features] measurement, or~~
	~~## FreeCAD 'Preferences->Document->SaveThumbnail' boolean indicates that a suitable feature may be in the FreeCAD API somewhere.~~
	~~# Have a FreeCAD workbench, such as the WebTools workbench, able to interpret the git log and these thumbnails in a meaningful way for the user~~
	Or simpler would be to not make a cache, but just use FreeCAD's thumbnail generation as part of each versioned document. But this is binary and shouldn't be versioned if at all possible... caching is the optimal solution as illustrated earlier.

	~~Related docs:~~
	~~[[Collaboration_Architecture]],~~
	~~[[FreeCAD_101]]~~
	~~This discussion page seemed like an ok sandbox to put my thoughts in before moving to a move formal page somewhere when I have a concrete solution.~~

	~~--[[User:Andrewusu\|Andrewusu]] ([[User talk:Andrewusu\|talk]]) 23:22, 2 January 2021 (UTC)~~
	]]

Andrewusu: /* FreeCAD v0.17 and newer */

2021-01-29T14:00:50Z

FreeCAD v0.17 and newer

← Older revision		Revision as of 14:00, 29 January 2021
Line 9:		Line 9:
	# [https://git.opensourceecology.de/hoijui/ReZipDoc hoijui/ReZipDoc] Open Source Ecology Germany, requires JRE 8 or newer [https://stackoverflow.com/a/54925238/1185900 writeup]		# [https://git.opensourceecology.de/hoijui/ReZipDoc hoijui/ReZipDoc] Open Source Ecology Germany, requires JRE 8 or newer [https://stackoverflow.com/a/54925238/1185900 writeup]
	# [https://github.com/callegar/Rezip callegar/Rezip], written in bash, won't work on Windows (unless cygwin is used). Might have unwanted permissions changes on files due to the rezip?		# [https://github.com/callegar/Rezip callegar/Rezip], written in bash, won't work on Windows (unless cygwin is used). Might have unwanted permissions changes on files due to the rezip?
	# [https://bitbucket.org/sippey/zippey Zippey], written in python~~, appears to be less optimal than the other two approaches, criticism of Zippey is in one of their write-ups~~. Zippey uses a different strategy than the other two so isn't compatible with them.		# [https://bitbucket.org/sippey/zippey Zippey], written in python. Zippey uses a different strategy than the other two so isn't compatible with them.

	The rezip tools essentially re-zip the zip archive with a compression of 0, to allow git to compress better given changes through time.		The rezip tools essentially re-zip the zip archive with a compression of 0, to allow git to compress better given changes through time. While Zippy is a bit different than the rezip tools... I'm not sure at a glance the implications of using it.

	If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes. I expect any user can use either they want, as long as they have the global git config filter set up for the tool they have, and that filter name matches what is in the repo's .gitattributes		If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes. I expect any user can use either they want, as long as they have the global git config filter set up for the tool they have, and that filter name matches what is in the repo's .gitattributes

Andrewusu: /* FreeCAD v0.17 and newer */

2021-01-29T12:21:47Z

FreeCAD v0.17 and newer

← Older revision		Revision as of 12:21, 29 January 2021
Line 14:		Line 14:

	If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes. I expect any user can use either they want, as long as they have the global git config filter set up for the tool they have, and that filter name matches what is in the repo's .gitattributes		If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes. I expect any user can use either they want, as long as they have the global git config filter set up for the tool they have, and that filter name matches what is in the repo's .gitattributes

			If a user hadn't properly set up a rezip tool and pushes their changes, then there won't be any problems other than a size increase. Which I suppose can be manually fixed later, but that is a headache.

	To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.		To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.

Andrewusu: /* FreeCAD v0.17 and newer */

2021-01-29T12:19:23Z

FreeCAD v0.17 and newer

← Older revision		Revision as of 12:19, 29 January 2021
Line 9:		Line 9:
	# [https://git.opensourceecology.de/hoijui/ReZipDoc hoijui/ReZipDoc] Open Source Ecology Germany, requires JRE 8 or newer [https://stackoverflow.com/a/54925238/1185900 writeup]		# [https://git.opensourceecology.de/hoijui/ReZipDoc hoijui/ReZipDoc] Open Source Ecology Germany, requires JRE 8 or newer [https://stackoverflow.com/a/54925238/1185900 writeup]
	# [https://github.com/callegar/Rezip callegar/Rezip], written in bash, won't work on Windows (unless cygwin is used). Might have unwanted permissions changes on files due to the rezip?		# [https://github.com/callegar/Rezip callegar/Rezip], written in bash, won't work on Windows (unless cygwin is used). Might have unwanted permissions changes on files due to the rezip?
	# [https://bitbucket.org/sippey/zippey Zippey], written in python, appears to be less optimal than the other two approaches.		# [https://bitbucket.org/sippey/zippey Zippey], written in python, appears to be less optimal than the other two approaches, criticism of Zippey is in one of their write-ups. Zippey uses a different strategy than the other two so isn't compatible with them.

	~~All these~~ tools do essentially~~, is~~ re-zip the zip archive with a compression of 0, to allow git to compress better given changes through time.		The rezip tools essentially re-zip the zip archive with a compression of 0, to allow git to compress better given changes through time.

	If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes.		If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes. I expect any user can use either they want, as long as they have the global git config filter set up for the tool they have, and that filter name matches what is in the repo's .gitattributes

	To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.		To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.

Andrewusu: /* FreeCAD v0.18 and newer (or v0.19 and newer?) */

2021-01-29T11:29:29Z

FreeCAD v0.18 and newer (or v0.19 and newer?)

← Older revision		Revision as of 11:29, 29 January 2021
Line 30:		Line 30:
	[[File:FreeCAD_simple_hiearichy.png]]		[[File:FreeCAD_simple_hiearichy.png]]

	The clutter of external documents in the tree view can be hidden by the setting 'View -> TreeView actions -> Single document'. But I'm still looking for a way to hide the Constraints, Elements, Parts containers.		The clutter of external documents in the tree view can be hidden by the setting 'View -> TreeView actions -> Single document'. But I'm still looking for a way to hide the Constraints, Elements, Parts containers- which would entail changing the TreeView to use a proper model-view separation. This change would also allow the ability to reorder items easily in the TreeView, something others would like to see implemented anyway.

	===FreeCAD v0.20 and newer===		===FreeCAD v0.20 and newer===

Andrewusu: /* FreeCAD v0.20 and newer */

2021-01-14T02:52:10Z

FreeCAD v0.20 and newer

Andrewusu: Undo revision 242082 by Andrewusu (talk)

2021-01-13T01:36:05Z

Undo revision 242082 by Andrewusu (talk)

← Older revision		Revision as of 01:36, 13 January 2021
Line 14:		Line 14:

	If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes.		If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes.

	It might be a good idea to have a [https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks git pre-commit hook] that verifies that any user with the repo has the filter set up that is in .gitattributes, as otherwise git does not fail or warn the user about the missing filter.

	To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.		To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.

Andrewusu: /* FreeCAD v0.17 and newer */

2021-01-13T01:34:43Z

FreeCAD v0.17 and newer

← Older revision		Revision as of 01:34, 13 January 2021
Line 14:		Line 14:

	If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes.		If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes.

			It might be a good idea to have a [https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks git pre-commit hook] that verifies that any user with the repo has the filter set up that is in .gitattributes, as otherwise git does not fail or warn the user about the missing filter.

	To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.		To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.

Andrewusu: /* FreeCAD v0.17 and newer */

2021-01-13T01:07:23Z

FreeCAD v0.17 and newer

← Older revision		Revision as of 01:07, 13 January 2021
Line 7:		Line 7:

	To prevent the explosion in space usage this mal-use would cause, a git filter should be set up for these *.fcstd files, such as:		To prevent the explosion in space usage this mal-use would cause, a git filter should be set up for these *.fcstd files, such as:
	~~# [https://forum.freecadweb.org/viewtopic.php?f=22&t=8688&start=30#p436343 costerwi/rezip], But requires Java JRE 8 or newer...~~		# [https://git.opensourceecology.de/hoijui/ReZipDoc hoijui/ReZipDoc] Open Source Ecology Germany, requires JRE 8 or newer [https://stackoverflow.com/a/54925238/1185900 writeup]
	## [https://git.opensourceecology.de/hoijui/ReZipDoc hoijui/ReZipDoc] Open Source Ecology Germany, requires JRE 8 or newer [https://stackoverflow.com/a/54925238/1185900 writeup]
	# [https://github.com/callegar/Rezip callegar/Rezip], written in bash, won't work on Windows (unless cygwin is used). Might have unwanted permissions changes on files due to the rezip?		# [https://github.com/callegar/Rezip callegar/Rezip], written in bash, won't work on Windows (unless cygwin is used). Might have unwanted permissions changes on files due to the rezip?
	# [https://bitbucket.org/sippey/zippey Zippey], written in python, appears to be less optimal than the other two approaches.		# [https://bitbucket.org/sippey/zippey Zippey], written in python, appears to be less optimal than the other two approaches.
Line 14:		Line 13:
	All these tools do essentially, is re-zip the zip archive with a compression of 0, to allow git to compress better given changes through time.		All these tools do essentially, is re-zip the zip archive with a compression of 0, to allow git to compress better given changes through time.

	~~callegar/Rezip in bash appears to be the most suitable to me as I don't have Java installed.~~ If you have Java then hoijui/ReZipDoc would be more robust.		If you have Java then hoijui/ReZipDoc would be more robust. callegar/Rezip in bash seems fine if you don't have Java installed and the git-config filter name matches what is in gitattributes.

	To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.		To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.

Andrewusu: /* FreeCAD v0.17 and newer */

2021-01-13T00:58:43Z

FreeCAD v0.17 and newer

← Older revision		Revision as of 00:58, 13 January 2021
Line 9:		Line 9:
	# [https://forum.freecadweb.org/viewtopic.php?f=22&t=8688&start=30#p436343 costerwi/rezip], But requires Java JRE 8 or newer...		# [https://forum.freecadweb.org/viewtopic.php?f=22&t=8688&start=30#p436343 costerwi/rezip], But requires Java JRE 8 or newer...
	## [https://git.opensourceecology.de/hoijui/ReZipDoc hoijui/ReZipDoc] Open Source Ecology Germany, requires JRE 8 or newer [https://stackoverflow.com/a/54925238/1185900 writeup]		## [https://git.opensourceecology.de/hoijui/ReZipDoc hoijui/ReZipDoc] Open Source Ecology Germany, requires JRE 8 or newer [https://stackoverflow.com/a/54925238/1185900 writeup]
	# [https://github.com/callegar/Rezip callegar/Rezip], written in bash, won't work on Windows (unless cygwin is used)		# [https://github.com/callegar/Rezip callegar/Rezip], written in bash, won't work on Windows (unless cygwin is used). Might have unwanted permissions changes on files due to the rezip?
	# [https://bitbucket.org/sippey/zippey Zippey], written in python, appears to be less optimal than the other two approaches.		# [https://bitbucket.org/sippey/zippey Zippey], written in python, appears to be less optimal than the other two approaches.

	callegar/Rezip in bash appears to be the most suitable to me. However, FreeCAD in a future version will support better integration with version control without such workarounds and additional workflow steps.		All these tools do essentially, is re-zip the zip archive with a compression of 0, to allow git to compress better given changes through time.

			callegar/Rezip in bash appears to be the most suitable to me as I don't have Java installed. If you have Java then hoijui/ReZipDoc would be more robust.

			To [https://git-scm.com/book/en/v2/Git-Internals-Packfiles see the results of the better compression], run `git gc`.

			However, FreeCAD in a future version will support better integration with version control without such re-zip workarounds and additional workflow steps (e.g. FreeCAD automatically controlling git after a save instead of the user controlling git after saving the file).

	===FreeCAD v0.18 and newer (or v0.19 and newer?)===		===FreeCAD v0.18 and newer (or v0.19 and newer?)===

← Older revision		Revision as of 02:52, 14 January 2021
Line 37:		Line 37:
	[[File:FreeCAD_realthunder_save_as_directory.png\|thumb\|Save as directory for version control integration in FreeCAD v0.20 and newer and realthunder's fork]]		[[File:FreeCAD_realthunder_save_as_directory.png\|thumb\|Save as directory for version control integration in FreeCAD v0.20 and newer and realthunder's fork]]

	realthunder has put in the plumbing to allow an ~~external tool/service~~ to automatically manage the version control of the CAD files.		realthunder has put in the plumbing to allow an FreeCAD module to automatically manage the version control of the CAD files.

	~~At this time the use of such beta features may be premature, but I imaging you'll want to migrate projects to use Assembly3 instead of Assembly2 anyway~~.

	====My envisioned solution====		====My envisioned solution====
Line 47:		Line 45:
	# Transparent git integration		# Transparent git integration
	## End-user does not have to interact with git or do any additional steps, other than save and enter a commit message		## End-user does not have to interact with git or do any additional steps, other than save and enter a commit message
	# ~~Service~~ will notify user of any update to a document they're working on		# Module will notify user of any update to a document they're working on

	Use FreeCAD v0.20 once available, or realthunder's present fork.		Use FreeCAD v0.20 once available, or realthunder's present fork.

	Set up a ~~service~~ to respond to the signals~~, e.g. [https://github.com/torfsen/service]~~. The signal data will include what files were modified/deleted/added. The ~~service~~ will:		Set up a Module to respond to the signals. The signal data will include what files were modified/deleted/added. The module will:
	# Interact with git. e.g. Commit the changes to a new revision.		# Interact with git. e.g. Commit the changes to a new revision.
	# Push the new commit to a remote repository, if a remote repository is designated in the document properties.		# Push the new commit to a remote repository, if a remote repository is designated in the document properties.
	# Put sub-assemblies into their own branch, and use git sub-repo to include those sub-assemblies in a subdirectory in the main branch (likely master).		# Put sub-assemblies into their own branch, and use git sub-repo to include those sub-assemblies in a subdirectory in the main branch (likely master).
	# If a remote repository was designated for any sub-assembly, the ~~service~~ will push any change for that sub-assembly to that sub-assembly.		# If a remote repository was designated for any sub-assembly, the module will push any change for that sub-assembly to that sub-assembly.

	In addition to the ~~service~~:		In addition to the module:
	# Add a means of adding properties to the document, so that the FreeCAD user can use the GUI to designate a remote version control repository to push/pull the changes to.		# Add a means of adding properties to the document, so that the FreeCAD user can use the GUI to designate a remote version control repository to push/pull the changes to.
	# Add a means for the user to enter a commit message when they save the document.		# Add a means for the user to enter a commit message when they save the document.
Line 66:		Line 64:
	A simple idea would be to have:		A simple idea would be to have:
	# An ".annotated_visual_history_cache" folder, which is listed in .gitignore (not versioned)		# An ".annotated_visual_history_cache" folder, which is listed in .gitignore (not versioned)
	# FreeCAD on opening a version controlled directory without, to interact with the ~~service~~ as the ~~service~~ iterates through git revisions, to cache each revision.		# FreeCAD on opening a version controlled directory without, to interact with the module as the module iterates through git revisions, to cache each revision.
	# On each revision, take a set of isometric snapshots rotating around the assembly, resized to say 64x64 px.		# On each revision, take a set of isometric snapshots rotating around the assembly, resized to say 64x64 px.
	## The ~~service~~ can possibly iterate through each revision [https://wiki.freecadweb.org/Embedding_FreeCADGui#Without_even_firing_up_the_FreeCAD_Gui without opening up the FreeCAD GUI].		## The module can possibly iterate through each revision [https://wiki.freecadweb.org/Embedding_FreeCADGui#Without_even_firing_up_the_FreeCAD_Gui without opening up the FreeCAD GUI].
	# An image processing utility will assign a complexity score to each snapshot, and the snapshot with the maximal complexity score will be selected as the thumbnail. A complexity score being a proxy measure of what image best illustrates the part!		# An image processing utility will assign a complexity score to each snapshot, and the snapshot with the maximal complexity score will be selected as the thumbnail. A complexity score being a proxy measure of what image best illustrates the part!
	## Filesize might suffice as an indirect measurement of complexity, the largest image being the most complex, otherwise,		## Filesize might suffice as an indirect measurement of complexity, the largest image being the most complex, otherwise,