Shipped Modules with FreeCAD

[onekk]

...
I suggest we also consider which workbenches are needed that don't exist today or are insufficient.

Not to be offtopic, and something that has been discussed elsewhere, but Surface creation could benefit from some love, as example many of us use CurvesWB that is developed in Python, but as example Curves WB use some functions taken from TiGL and ported to Python by @Chris_G (Many thanks)

And there are a couple if other WB like Silk and Curved Surfaces (sorry if name is not correct) that has interesting implementations.

Discussing about to incorporate some of them in FreeCAD obviously with author permission wil be a thing to evaluate?

Regards

Carlo D.

[onekk]

...
What's the point of moving these already established functions as default FC functions to a different container, making the WB programmer's life hell?

IMHO it depends.

If something is incorporated and rationalised in FreeCAD sources it will be probably better integrated, if you think in a perspective way, if something similar should happen better to be at a "version bump".

See as example the many efforts undergoing to port FC sources to a more modern C++ standard and Qt6 that will be needed in future.

So probably "why not now" as users will have with TNP mitigation and various other thing that are boiling for sure some need to adapt to new things.

Same for a WB maintainer, probably for some time it may be necessary to have two version of some WB if TNP will change something so it will be a good move to say that there is a version from 1.0 onward.

Kind Regard

Carlo D.

[Zolko]

why removing something useful and well known just to resize of 0.1%...

because it's not useful for everybody. What I use all the time are the fasteners from the fasteners workbench, which I suspect are used by much more people than the openscad things, and yet it's an external WB. And there is no problem with that, it's the very purpose of a modular design.

OPENSCAD has a lot of useful python functions in:

If that's your opinion, nothing would prevent you from installing it as an external addon.

What you're basically saying is that bloatware doesn't matter. How FreeCAD is supposed to become professional and go to version 1.0 with such a mentality is beyond my understanding.

[aapo]

because it's not useful for everybody. What I use all the time are the fasteners from the fasteners workbench, which I suspect are used by much more people than the openscad things, and yet it's an external WB. And there is no problem with that, it's the very purpose of a modular design.

I think what you say about modular design is very true, and that is the truly strong thing about the Python integration of FreeCAD: There are many good Python workbenches, that are truly independent in the sense that the core FreeCAD does not depend on these additions in any way. These extra goodies are purely optional for the user's benefit.

However, unfortunately, any workbench written even partly with C++ needs to be included in the core package, because of practical compilation reasons. I'm sure it's technically possible to make an external C++ workbench and distribute it as object and/or source files to users, but in order for it to work the user needs to compile or link it; or otherwise the workbench developer would need to separately produce a compiled module for every platform and compiler combination that FreeCAD is distributed for, which might turn out to be very cumbersome for the developer (and users). I think that forces any C++ based workbench either to be included in the core package, or to disappear completely.

There are some core C++ workbenches, like PartDesign and TechDraw, that probably need to be C++ in order to use core C++ functions directly. That said, it'd probably wise to write as many workbenches as possible with Python, so that there'd be no compilation dependency with the core, and they could be offered separately through the Addon Manager. So, I'd postulate that a C++ workbench for things that don't need to be integrated tightly with the core would be a bad idea. You'd lose the practical modularity (because of the package distribution).

[onekk]

...
So, I'd postulate that a C++ workbench for things that don't need to be integrated tightly with the core would be a bad idea. You'd lose the practical modularity (because of the package distribution).

You are lefting out the fact that despite with Python 3.11 should be more fast (with speed improvements as a goal of new version by Python developers announcements) it is not fast as C++.

So reasons to make integration of some packages in core FreeCAD could even be speed improvements.

If you are not using a WB it should be easy to "deactivate" it to not have it in "main interface" menu in toolbars.

A compiled FreeCAD for a distribution is not very big much less than 100 MB, obviously if you measure FreeCAD dimension using the AppImage it is a different matter.

But this has been discussed many times and AppImages are used by many to distribute softwares in a distribution agnostic way, so FreeCAD is not the only one affected.

Regards

Carlo D.



Regards

Carlo D.

[GeneFC]

If you are not using a WB it should be easy to "deactivate" it to not have it in "main interface" menu in toolbars.

That has been true for a long time. Simple setting in Preferences.

I have only about 10 WB entries in my "main interface" for toolbars. Occasionally I load another one, but not often.

Gene

[onekk]

..
That has been true for a long time. Simple setting in Preferences.
...

In fact, we are substantially telling same thing.

I'm simply saying that there is no need to delete a WB from sources only to have less cluttered interface, as it is easy to have them "hidden" from the interface.

The other matter is that is a reasonable approach to delete obsolete and deprecated WB if there is no good reason to keep them, as example for compatibility reason.
This will easier things to maintainer to as example keep codebase in line with new compilers requirements.

The simple fact that "most users don't use them" as some users as brought as a good reason, lead to the fact that is difficult guess even "how much users" are using FreeCAD, so every decision should even consider that many times the "noise created by unsatisfied" users are difficult to compare with "silent majority" of happy users, and you could only make a decision if you know the two figures to make a comparison.

Sadly in OpenSource is difficult to guess how much "satisfied users" a program have, as it is difficult to count as example how much users are using "distribution supplied" packages, so you should take in account even the above sociological approach about "noisy minority" and "silent majority".


Kind Regards

Carlo D.

[easyw-fc]

because it's not useful for everybody.

everybody or you?

OPENSCAD has a lot of useful python functions in:

If that's your opinion, nothing would prevent you from installing it as an external addon.
What you're basically saying is that bloatware doesn't matter. How FreeCAD is supposed to become professional and go to version 1.0 with such a mentality is beyond my understanding.

You are considering a default must to be included only what is useful for your workflow...
You are considering as optional 'Draft' and 'Arch' but not 'Fem' and similar ...
Moreover you will be in charge for replying to all user that are using Openscad, Draft, Arch that would need to add something that was a default almost since FreeCAD has started...

I think all I needed to say is in my first reply :

because it's not useful for everybody.

everybody or you?

..
That has been true for a long time. Simple setting in Preferences.
...

In fact, we are substantially telling same thing.

I'm simply saying that there is no need to delete a WB from sources only to have less cluttered interface, as it is easy to have them "hidden" from the interface.

I agree so much... Zolko started this because he said:

I can't but observe that the download size of the core FreeCAD grows and grows with each release.

He started this just for the increasing size of the FC image size, which is very limited related to the discussed WBs, as he erroneously included source files in his 'analysis'.

[Zolko]

However, unfortunately, any workbench written even partly with C++ needs to be included in the core package, because of practical compilation reasons.

yes, you're right. The differentiation between core and external package depends not only on usefulness but also on technicalities. That-is, until "we" find a way to include external packages that need compiled stuff. Let's simplify things and leave that for later.

On the other hand, if we follow this logic, any Python workbench can – technically – be provided as an addon. So the question becomes: what potential "externalable" should FreeCAD provide in "core" ? For example, OpenScad : the question is not whether is "good", but rather "what's the best way to provide the functionality for those people that need it, without encumbering those that don't" ?

[aapo]

On the other hand, if we follow this logic, any Python workbench can – technically – be provided as an addon. So the question becomes: what potential "externalable" should FreeCAD provide in "core" ? For example, OpenScad : the question is not whether is "good", but rather "what's the best way to provide the functionality for those people that need it, without encumbering those that don't" ?

That is a fair point, because that particular workbench appears to be coded in Python, so technically it could well be an addon. That said, I'm not sure what would be a good way to decide which workbenches should be included in the default core installation. Voting is always a bit problematic in a meritocracy (as opposed to a democracy), but I have no clue what the current system to select core workbenches actually is..? There is probably some historical baggage, as I suspect that when there was not that many workbenches most additions were simply included without much discussion in the beginning, but what about now? Maybe it's just that devs are supposed to make PRs for master to include/remove workbenches, and hope that the PR reaches consensus and will be merged.

This thread certainly raises an interesting point about the workbench availability in FreeCAD. Especially in the future, as it seems that FreeCAD popularity is steeply increasing, and that'll probably generate a large number of new workbenches of varying quality. Luckily, if most of them will be coded in Python, they can be efficiently managed with the Addon Manager. At some point it might be wise to apply some metadata classification filters to the workbenches provided in the Addon Manager, so that new users would more easily find the essential addon workbenches not in the core distribution (like Asm2/3/4, Gears, Fasteners, Curves, Sheet Metal). All the workbenches could be classified A) Core B) Essential C) Established D) Standard E) Development, or some other fashion. But, of course, the problem would be how to make the classifications, because they'd be quite subjective choices and there would be a lot of distinct opinions about such classification.