[Problem] Many names in FreeCAD are confusing #10205
Replies: 6 comments 4 replies
-
people have questioned this assertion before, is the Part WB really CSG? I'm uncertain of the actual definition |
Beta Was this translation helpful? Give feedback.
-
|
There can be opposition against renaming among programmers. Good example: #8730. IMO it is necessary to address that first before investing any serious time in this. |
Beta Was this translation helpful? Give feedback.
-
|
The idea here is not to worry so much about the internal names of commands, or the internal structure of the code, but to not allow those coding decisions drive how the user interface is presented. It may make sense to group various things together into a Mod (in the code) that do not necessarily have to be presented together in the user interface. The names of Workbenches do not have to match the names of the underlying Mods in the code. Forgetting entirely about what things are called internally, what groupings and names make sense to end users? |
Beta Was this translation helpful? Give feedback.
-
|
Command names are communicated to the user. They determine the names of command reference pages for example. Discrepancies between those names and what is presented to the user in the UI should be avoided. Some more examples:
What is suggested here may lead to the last example becoming standard practice. Which would not be a good idea IMO, and also go against the workbench concept of FreeCAD. |
Beta Was this translation helpful? Give feedback.
-
|
This only applies to users viewing the interface in English, of course. Those UI strings are translatable, so relying on the UI showing exactly what the underlying name of the command is has already been irrevocably broken by our providing the interface in multiple languages. |
Beta Was this translation helpful? Give feedback.
-
|
agreed with chennes, but I still think the Cube in Part_Box should be changed to Box, that one is just bonkers. I'm assuming the Draft_Wire command was not renamed because it wasn't worth breaking the API. And the Part_SectionCut situation was justified already |
Beta Was this translation helpful? Give feedback.
-
|
(My 2 cents here) I agree Part_commands should stay defined in Part_ and not be placed in Std_ menus... As alex prokoudine remembered on discord, Blender is now using a kind of "workbenches concept" too, our workbench concept is great, we should keep it and enhance it and make it more accessible and understandable to new users, not go against it |
Beta Was this translation helpful? Give feedback.
-
|
I'm certainly not arguing that we should abandon Workbenches -- I'm arguing that we shouldn't let the underlying structure of the code dictate how we present features to the end user. Just because it made sense to implement Measure in the Part module (code) doesn't mean that it should only show in the "Part Workbench" of the user interface. We can and should break the code down into many small modules (I almost wrote "parts" there!! 😆 ), but I don't think that should force our hand as to how we display those commands in the interface. |
Beta Was this translation helpful? Give feedback.
-
|
But some things that need to be implemented in Part or other modules are MUCH better shown as global tools. For example the cut tool, the measurement tools, arguably the PD datum objects.... it is not good UX that you need to go to the Part WB to be able to measure things when that is relevant in any wb. |
Beta Was this translation helpful? Give feedback.
-
|
Agree with both of you. But then, probably, it's best to separate the measurement tools into their own UI element (toolbar, menu) and have that element appear in other workbenches, rather than mixing part commands with std commands (not 100% sure of what i'm saying, but it feels like we should maintain some kind of transparency there between what the user sees and how FreeCAd is structured internally) At least in the "core" workbenches. Of course addons, or even less "fundamental" workbenches, can remix anything as they see fit... |
Beta Was this translation helpful? Give feedback.
-
Is there an existing issue for this?
Full version info
Subproject(s) affected?
None
Problem description
In the GUI of FreeCAD we have many things (workbenches, commands, etc.) that either do not use a standard term (when there is one for the item in question), or that use a term in a non-standard way. This is currently a placeholder issue that will eventually contain a "map" of existing name to proposed names and explanations of those choices. For example, we use "Part" to describe our Constructive Solid Geometry Workbench, so perhaps "Part CSG" (or something along those lines) would aid users in making the distinction.
There are many interested parties here, but in particular tutorial authors should be consulted since they bear the brunt of the FreeCAD training work.
Anything else?
No response
Code of Conduct
Beta Was this translation helpful? Give feedback.
All reactions