you can create your toolBar
depend number programmer volunteer for this feature
mario
you can create your toolBar
depend number programmer volunteer for this feature
this exists in Assembly4's measurement tool
this exists in Assembly4's measurement toolmaxwxyz wrote: ↑Sun May 07, 2023 9:04 am It would be beneficial if the tool could support or asks for the selection mode of the first and second input, e.g. any geometry, edge only, and so on.
...
It would be also great if the tool could output the result in coordinates (absolute and relative to first selection)
At the very low level, to keep things "simple" and maintainable/extensible implementation, I would have imagined something like :hlorus wrote: ↑Sun May 07, 2023 3:07 pm In the proposal i've outlined an inital implementation approach where a measurement command and a parameric object would be defined by base freecad. These would then handle the whole measurement logic and user interface. Workbenches that implement additional geomtery types would simply be responsible to translate the specific geometry into some abstract representation. Do people have an opinion / feedback on this approach? Or more specifically:
Yes there are. How are you imagining it ? All Python ? C++ calling Python extensions ?- Are there already other base commands in FC which get extended by workbenches?
Yes we should find. But how are you imagining measures to be displayed ? Is that something permanent (saved in document) ? Does it appear in the tree as an object ?- Is there already an abstract representation of geometry in FreeCAD's base that could be used for the measure command which shouldn't know about specific geometry types?
Interesting, workbenches would then implement an inherited observer class while the measurement class will be defined only once in FC base?
My plan was to have only one actual command. Workbenches would register "GeometryTargets" at startup, either from python or c++. These would be responsible to represent specific geometry in an abstract way. E.g. an angle mesurement would require 2 line GeometryTargets which could be represented in a variety of ways, like by 2 mesh vertices, a mesh line or a än edge of a solid etc.Yes there are. How are you imagining it ? All Python ? C++ calling Python extensions ?
As a parametric element which is displayed in the tree and has s representation in the viewport. However the same infrastructure should also support to display just a temporary measurement while running the command.Yes we should find. But how are you imagining measures to be displayed ? Is that something permanent (saved in document) ? Does it appear in the tree as an object ?
Not necessarily an observer. It could be that workbenches just have to implement a specific method that in turn will be called by the base system.
Yes, something like this makes sense.My plan was to have only one actual command. Workbenches would register "GeometryTargets" at startup, either from python or c++. These would be responsible to represent specific geometry in an abstract way. E.g. an angle mesurement would require 2 line GeometryTargets which could be represented in a variety of ways, like by 2 mesh vertices, a mesh line or a än edge of a solid etc.
Parametric is challenging at the moment because it relies on topology, which isn't stable yet (work is on going). But still interesting to foresee such a possibility.As a parametric element which is displayed in the tree and has s representation in the viewport. However the same infrastructure should also support to display just a temporary measurement while running the command.
There have been two directions in the past: One is to create an actual object that appears in the tree view, another is a kind of "shallow" measurement system that displays measurements in the 3D view (and maybe other outputs such as the Report window) but does not create an actual object in the model.hlorus wrote: ↑Sun May 07, 2023 3:07 pm In the proposal I've outlined an initial implementation approach where a measurement command and a parametric object would be defined by base freecad. These would then handle the whole measurement logic and user interface. Workbenches that implement additional geometry types would simply be responsible to translate the specific geometry into some abstract representation. Do people have an opinion / feedback on this approach? Or more specifically:
Thanks for the pointer, i'll definitely investigate that system.yorik wrote: ↑Mon May 08, 2023 8:35 am Welcome on board David! Looking forward to this!
If you go the object way, I would imagine it could be like the basic Part Feature: There is a base class, that is used by all Part objects, and has a basic view provider, and it can be extended both in C++ and in Python.
Basically you'd need to think of a "common" set of properties, behaviours, etc... that all those usecases would need. Thinking out loud, I'd say you should focus on getting clear, useful info out of the measurement, and a nice UX workflow to place those dimensions on a model.hlorus wrote: ↑Mon May 08, 2023 11:14 am With such a base feature what functionality would features that are inherited from it implement? Would they simply be Mesurement objects, like MeshMesurement, PartDesignMesurement that support measurements in the scope of their workbench?
IMO that could be kinda limiting as it wouldn't ever allow a measurement between elements of different geometry types.