Workbench Versions

[catman]

https://github.com/FreeCAD/FreeCAD-addons/issues/29

Although if I'm not mistaken, @mnesarco is proposing a different format in his ExtMan project which improves the Addon Manager as mentioned before.

Thanks for the link. So the idea is to have an additional *.md file that will be parsed?
That reminds me on the Doxygen mantra that "everything outside the code will start to deviate soon". WBs like Manipulator already display the version in one of their dialogs (help). I think they would favor a codeable solution.

[mnesarco]

That reminds me on the Doxygen mantra that "everything outside the code will start to deviate soon". WBs like Manipulator already display the version in one of their dialogs (help). I think they would favor a codeable solution.

That's the problem, without an standard metadata structure, each workbench reinvent the wheel, showing the version is only one of the myriad of things that should be managed directly by freecad based on package metadata.

[catman]

showing the version is only one of the myriad of things that should be managed directly by freecad

I think every WB developer will be happy about this

based on package metadata.

That this the difficult part. Great if that works without maintaining something extra in the repository. If something needs to be maintained, thats where it will work or fail, depending on the effort required by the repository maintainers. Probably there is no really good solution in that case, only a least effort solution. My point was about this part only

[vanuan]

I see several tasks here.

1. Display a list of workbenches in the about screen
2. Copy workbench info when user presses copy
3. Add version metadata to each workbench
4. Introduce a release management policy

The most difficult one is a release management policy. That is, how to get workbench authors to declare compatibility/dependency on various workbenches. And how to make sure they make releases rather than asking users to use git master branch. And if making releases requires to upload workbench to some repository, how to maintain and self-manage that repository.

[vocx]

...And how to make sure they make releases rather than asking users to use git master branch.

It's very hard to convince developers to do things the way you want, because they will usually do it the way they feel most comfortable. Also, many workbench developers aren't expert programmers, many of them are amateurs who just wanted to hack together something useful; so they aren't going to apply the best practices of software development, or think too much about future maintenance.

So, my idea, is that we should be tougher on the selection of workbenches that make it to the Addon Manager repository. If you want to be in this repository, you need to follow some rules. Otherwise, the workbench will not be included, although it can still be installed manually.

...
And if making releases requires to upload workbench to some repository, how to maintain and self-manage that repository.

The way it is done at the moment is that the FreeCAD-Addon repository just has links to the individual repositories of the external workbenches. So no uploading to a specific repository is necessary. Currently the Addon Manager just takes the master branch, but I have the impression that with mnesarco's work it would be relatively easy to pick any particular branch. So definitely the external workbench authors should consider using tags or branches to specify the version of their workbenches, this would help a lot define what is compatible with a certain version of FreeCAD.

[galou_breizh]

This is probably an overkill but this could be done in the same manner as is done with ROS2 (https://index.ros.org/doc/ros2/) which is a package-based system with a meta-builder, colcon. Switching to such a system would require that the whole FreeCAD uses this system. Package metadata are written in a `package.xml` file when dependencies can be written with optional minimal and maximal versions. The `package.xml` is used among others to build, to run unit-test, and to create the package for different distributions. ROS developers develop their code where they want, then there is a release repository that developers must "declare" in a special public file if they want the build farm to build their code as package for various distributions. colcon is supposed to work on all operating systems.

I actually wanted to demo how to switch the FreeCAD code base to colcon but didn't find the time yet.

Cheers,
Gaël

[vanuan]

Wrt to packaging, I'd rather see preconfigured distributions/presets:

• For 3D printing enthusiasts
• For mechanical engineers
• For civil engineers
• For architects

That is, the goal of versioning is to satisfy user needs by ensuring the compatibility of workbench sets. But since we don't have workbench sets, everything would need to be compatible with everything. This is not realistic.

[vocx]

Wrt to packaging, I'd rather see preconfigured distributions/presets:

I think since FreeCAD is sufficiently general, it is good that it has a base modelling core (Part), and a few libraries to do more advanced work (Sketcher/PartDesign, TechDraw, Draft, Arch, Path, FEM). So it packs enough batteries to start doing work without relying on external workbenches. I think that balance is preserved in something like the BIM Workbench, which extends Arch, to do more advanced architectural work; but the basics of modelling a building can be done without much problem in the base Arch Workbench.

In my opinion, workbench developers should put more effort in harmonizing their workbenches with the base system.

This also reminds me of this thread: [Discussion] Defining core workbenches

Various users think that your idea of having a preset of workbenches or categories also makes sense.

[vanuan]

I think since FreeCAD is sufficiently general, it is good that it has a base...

with the base system.

Yeap, another part of the problem is defining the base. To me, the base is the minimal FreeCAD file that have some objects with some properties.

Then, on top of the object model, there should be some object taxonomy and schema validation. Those taxonomies should be versioned and clearly documented. Ideally, a file specification should be published so that independent workbenches or completely separate applications could read and write the file given all the objects/properties are supported/well-known.

Then, there should be C++/Python APIs that modify/read the object model and emit signals when it's changed. Ideally, those are developed as a separate library in a different repository, so that many tools/workbenches can align to it and request an extension.

On top of those C++/Python APIs there should be the business layer: a set of rules to make sure the object model is consistent. That's the hard part - how to define the scope of the workbench, how to specify a set of properties the workbench can modify and listen to. Which version of the taxonomy it supports. How to ensure that the meaning/behavior of the property is not changed between versions (compatibility/deprecation policy).

On top of the business layer, there's a set of actions user wants to do. Those are use cases of the workbench - high-level representation of the user intent. This is so-called controller or interactor layer.

On top of user interactions, there's a presentation layer - a compact definition of actual widgets and UI elements to be displayed and their state.

So according to the above, the base would be:

• A set of object specifications/taxonomies
• A set of APIs to modify/subscribe to object properties in a given taxonomy
• A set of APIs to define a set of business rules
• A set of APIs to define user interactions with an object and maybe some standard interactions common for all workbenches
• A set of APIs to define object presentation

So for starters, I would try to define the following:

• Global/User Settings/Preferences. How many are there? What they mean? What makes a user preference rather than a property of an object? What's the policy of introducing new preferences by the workbench?
• Document properties. Is there such a concept? How can we ensure that the document opened by two users has the same object model? That is, object model is not impacted by the user preferences. Should the default values of properties be stored in the document? WHich ones?
• Object properties. How many object types are there? Which properties are there? Which properties can reference which object types? Are the objects duck-typed or there should be a strict schema?
• Visibility guidelines (what the user sees). Which object types are shown in the document tree? Which properties are shown in the properties view? What defines nesting? Are edges and points true objects or generated on the fly?
• Naming/Referencing/Identification. How to identify an object? Should UUID be used underneath the user provided strings? How to deal with toponaming? What if an object doesn't have any faces/edges/points? What if a type of an object is changed?

[vocx]

...
So according to the above, the base would be:

• A set of object specifications/taxonomies
• A set of APIs to modify/subscribe to object properties in a given taxonomy
• A set of APIs to define a set of business rules
• A set of APIs to define user interactions with an object and maybe some standard interactions common for all workbenches
• A set of APIs to define object presentation

...

I think that's noble and all, but it sounds like a lot of "formal" work. Most developers in FreeCAD work in a more fluid way; they are not professional programmers, they implement something that they want, to address a problem that they have, but they don't necessarily care about formalities like code documentation, wiki documentation, or maintaining or breaking backwards compatibility. That's just the reality of the project at the moment.

In order to do all that you mention, we need more people like yourself, who want to establish some order. You have to lead the way, you have to show people how it's done, otherwise most other developers won't do it.

Did you read the past discussion? Discussion: FreeCAD is not ready for 1.0

I posit that we need better organization in order to release a FreeCAD 1.0, at which point it should be very stable and mature. Other people think that the software is already good enough, and it should have been 1.0 a long time ago. So, there are opposing views, those who want to grow FreeCAD in a more ordered manner, and those who just want more people to use the software, no matter if it's stable or not.