After discussion in several recent PR review meetings the Maintainer
team has decided to roll back some recent work on object naming in STEP
files. Inadequate automated testing has led to a situation where every
change made to address one bug introduces another someplace else. It
is difficult to determine which, if any, of these fixes represent an
appropriate path forward, versus fixing a symptom rather than the
underlying problem.
---
Revert "[pre-commit.ci] auto fixes from pre-commit.com hooks"
This reverts commit 59715114f5.
Revert "core: fix various issues exporting step files, ie. #25540#24962#25567"
This reverts commit e226e9b06e.
Revert "export: step file preserve last feature when exporting step file, fix issue #25567"
This reverts commit 9c48c9a3e3.
Revert "core: preserve body name in step file when exporting part that contains body with feature, fixes#24962"
This reverts commit 246218b28b.
Revert "Import: STEP export preserve body names (#25042)"
This reverts commit f218c5f25c.
Revert "Import: Export tip when body is selected (#24678)"
This reverts commit 6fd6558040.
* Core: Fix completer popup adjustment after 'Tab' pressing
Completer popup in Expression Editor is now positioned and sized after pressing 'Tab'. This was missing when feature was added.
* Core: Extend completer popup list to up 20 elements or up to screen edge
Completer popup will now show up to 20 elements or will be limited to screen edge; if limited < 3 rows, popup will be displayed over cursor.
* Core: Fix completer wrapping on secondary screens
* Core: Fix completer positioning when includes long entries
* Core: Fix linter complaints
* sketcher: fix issue #25992 keep snapped position when releasing mosue for updated sketch points
* Update src/Mod/Sketcher/Gui/ViewProviderSketch.cpp
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
---------
Co-authored-by: Chris Hennes <chennes@pioneerlibrarysystem.org>
- Any action part of the application menu will trigger based on shortcut
when a native file dialog is open
- Another way to fix this is to switch out the application menu, but
afaict it requires writing native objective-c code. I think that's too
much complexity just to get cmd+c/cmd+v in these file dialogs
- For now, just disable the actions so that select-all, rotate-left, etc
don't trigger when pressed in these dialogs
- I've implemented an RAII wrapper to disable this. It should take
pointers which should be fine because all of these dialog calls are
blocking (so in principle nothing can change underneath).
I'm quite sure this won't have any adverse effects on other platforms,
but will need help from other developers to test in case.
The current code in \src\Mod\CAM\Path\Main\Gui\Job.py (line 719) ignores selected stock selections. In case of e.g. cloned stock objects it defaults to the first item in the combolist, showing a wrong stock selection.
The cause lies in comparing different strings to find a label match, but one string object is generic (short name) while the other one has a suffix created during the clone process. The strings never match and the ridgid string comparison fails. I recommend using a partial (needle in haystack) string comparison.
This PR adds migration for toolbit units by automatically infering the
Units (Metric/Imperial) from toolbit parameter strings and sets the
Units property if missing. It adds a utility function to detect units
from JSON. This is done at the JSON level during migration to ensure
that all toolbits have the correct Units property set.
src/Mod/CAM/Path/Tool/toolbit/migration.py:
- Infer Units from parameter strings if not set during migration
- Set Units property and log inference
- Refactor migration logic for clarity and reliability
src/Mod/CAM/Path/Tool/toolbit/models/base.py:
- Use Path.Log.debug instead of print when adding Units property
src/Mod/CAM/Path/Tool/toolbit/util.py:
- Add units_from_json() to infer Metric/Imperial from parameter strings
- It seems that on MacOS (vs other platforms), shortcuts for items in
the application menu are given 'ultimate' priority, and will even take
precedence over text inputs
- There is a mechanism in QT (I believe designed with mac in mind) to
try to 'block' these shortcuts and send it to the focus instead. It's
'Shortcut Override': https://wiki.qt.io/ShortcutOverride
- Initially I was going to only apply this check when it's a Command
that overrides a known line-editing shortcut, but I figure it's
simpler to just always apply it when editing text. I can't really
imagine a user wanting to use an application shortcut while editing
text, but if there's some compelling use-case for this then let me know
and I'll add a further filter.
I'm quite optimistic that this won't have any ill-effects on other
platforms, but I'll need help from others to test this.