* [CAM] fix biggest performance problems in ramp dressup
key items:
- finding the index of the current edge with edeges.index(edge) was very
expensive; fixed by tracking the index while looping
- checking which edges were rapids with edge equality was also
expensive; fixed by keeping a list of indexes of rapid input edges,
and tagging output edges with whether or not they are rapids
* [CAM] comment out Path.Log.debug in hot segments of ramping code
Even when low level logs are supposed to be suppressed, Path.Log.debug
takes take invoking traceback.extract_stack. This time adds up if logs
are invoked in frequently run loops.
* Fix CAM test
* [CAM] reimplment ramp method 1 with faster code
* [CAM] reimplement ramp methods 2, 3, and helix
* [CAM] patch to make output match original
* [CAM] ramping full performance + functionality fix
* [CAM] extract tool controller ui elements into their own file
* [CAM] make the changes in the tool controller UI only apply when ok is clicked
* [CAM] Add tool controller edit panel to the Profile operation
* [CAM] Add copy button to in-operation tool controller editor
* [CAM] clean up changes
* [CAM] Add tool controller edit UI to all operations
Notes on changes that were not a simple copy/paste job from the changes
I made for Profile:
- Deburr: changed TC/coolant rows from 1 and 2 to 0 and 1
- Probe: didn't work at all initially due to bug in main where ShapeName
changed to ShapeType. I added a utility for reading either a ShapeType
or a ShapeName (check for both properties, convert ShapeType to lower
case) and applied it to probe and camotics
- Drilling: moved Keep Tool Down checkbox up from row 8 to row 2 (all
intermediate rows were missing) and added the edit checkbox in row 3
below it
- VBit, Probe (or anything else that requires a specific tool type): in
Base.py setupToolController(), I added a check to see if the currently
selected tool is an invalid type, and if so and there is a valid tool,
then change to that one. This fixes two UI bugs. Plausibly pre-existing,
if there is one valid tool and an invalid tool is selected, it's
impossible to switch to the valid one because you can't generate a combo
box change event for the new tool. Definitely new: if an invalid tool is
selected and there are no valid tools, the combo box will be empty but
the new tool controller edit utility will let you edit the current TC
anyway.
- Thread Milling: replaced the Tool Controller GroupBox with the
standard QFrame layout, and added the checkbox. Note that this
operation doesn't have a UI element for coolant -- likely a bug, but I
didn't look into it
- Surface: Changed from form layout to grid layout. Deleted an old
SurfaceEdit.ui file -- it was replaced with PageOpSurfaceEdit.ui in
2017 but not deleted (commit 8637831132)
- Waterline: Changed from form layout to grid layout
* [CAM] Bug fixes
setupUi() wasn't called on the tool controller editor, preventing
changes in its UI from being written back to the object immediately.
This caused weird behavior where if you edited a field twice it would
reset the second time it was focused
Added a hook to automatically update the TC combo box when the TC name
(or anything else about it, since that was easier) changes
* Fix usage of QSignalBlockers
* [CAM] Block scroll events on tool number and spindle direction when not
focused
Specifically, if you mouse over either of these UI elements and use the
scroll wheel, it used to focus the element and change its value. This
commit makes it do neither of those things, for these specific elements,
as a measure against users accidentally changing these values.
* disable tcNumber edit field in operations panel
* Add "New tool controller" option to TC combo box
When selected, it opens (toggles, technically) the tool bit dock and
returns to the previous selection. Adding a new tool controller using
the dock (already, before this commit) automatically switches the
operation's tool controller to the new one
* Add "Copy" option to tool controller combo box
* Copy TC function only in combo box, no button
* [CAM] update in-operation "new tool controller" function to use a dialog
* [CAM] make the tool selector always a dialog and never a dock
* remove spacer from ToolControllerEdit.ui to fix exces white space
* [CAM] change tool dialog default sizing/spacing
* [CAM] fix bug where copying tool controller doesn't copy all values
As the title says - we can get into a scenario where user can specify
constraint equal to 0.0, or similar small value and the scale factor
will become 0 as well, resulting in all geometry trying to be rescaled
to degenerate geometry.
So this patch filters those values out, and bails out from auto-scaling
leaving only solver to handle this value.
* feat(profiles): Add square metric t-slot profiles
Request also allows to use profiles in quetzal workbench
* fix(ProfileTaskPanel): fix class name on proxy & sufix
* refactor(ArchProfile, Arch): Modify T-s to TSLOT
and also fix hole_diameter not assigned
* fix(ArchProfile,profiles): Change t slot profile class Name
While the advice is good, the overwhelming majority of "do-while" warnings that come up in our codebase are macros using a standard pattern using a do-while loop to encapsulate the macro's work.
* PartDesign: Enable selecting a sketch as base plane of another sketch
* to squash
* Part: Attacher: enable attaching to empty objects such as empty Sketch or Body.
* Update SketchWorkflow.cpp
Removes check on function parameters for height & length (first
introduced in commit 5217b24), relying on values assigned in "obj".
If those params are present, they're assigned to "obj" anyway, so
the check is redundant.
Fixes#22585
The context menu of the property view shows a "Copy" action for
properties with which the value of the property can be copied to the
clipboard. When multiple properties are selected, this menu item
appears multiple times and in that case it copies the name of one of the
properties. This commit fixes this.
With PR 19941 there is a regression where parts of the document
won't be restored. This is caused by overriding the virtual method
handleChangedPropertyType() but not calling the method of the base class.
While searching for a fix another problem showed up where (due to the
incomplete loading) exceptions are thrown but not handled within TD.
Therefore the method recompute() is overridden in DrawView to also handle
OCC exceptions.
Unlike in the bug description of issue 19654 the user doesn't have
to preselect an edge in the 3D view but first start the dimension
command and then select an edge.
This commit adds some security checks to TechDrawHandler::quit(),
TechDrawHandler::getPage() and TDHandlerDimension::onSelectionChanged()
to be on the safe side that no null pointers are dereferenced.
But the ultimative fix for this whole problem is to change
activateHandler() and immediately delete the passed TechDrawHandler if
it fails to find the appropriate QGVPage. This is needed as otherwise
the handler behaves like a ghost object that affects the selection
mechanism and disallows to select anything in the 3D view or the tree
view.
Fixes issue 19654
When validating distance joints, parts would move from preview position to
a different valid solution. This was caused by preSolve() being called
inconsistently - applied during offset changes for all joint types, but
distance joints are not in JointUsingPreSolve list.
Fix: Only call preSolve() for joint types that are designed to use it,
matching the logic used elsewhere in the codebase.
