Versions QT5 OK on WIN7, WIN10 and LINUX

My PlanetCNCW64 software accepts G41/42 but gave an error on generated g-code G40 (“Arc without IJK or R is not valid” G40 X85.6 Y62.24 Their bug?). So, I had to fill “Interpolate axes with line segments” in CAM Configuration. A little window QCAD CAM “Regenerating tool path…” opens, shows 50% all the time, and a button “Abort” that closes that window when clicked, but doesn’t stop the process; a lot of messages “regenerating tool paths…” run at the bottom with great speed, as expected.

With QT6 but not QT5, after a while, these messages start slowing more and more, when I believe the arc segments are being generated, but keep a normal speed on lines, till the program freezes. During this process, with both QT6 and QT5, the memory used is growing, but is not released until the program is closed. Garbage collection problem?

Expected is a vector with a magnitude strictly not larger than the given range.

But the behavior is very different in regards with the shape:
- RArc: Unused, compare strictRange with distance to center minus radius
- RLine: Only applied for non-perpendicular vectors towards the nearest endpoint if limited
- RCircle: Unused, see RArc
There is always a perpendicular vector towards an RCircle
- REllipse: Unused, there are 0-4 normals for a full or limited ellipse shape
Compare strictRange with distance to (nearest) point on ellipse …
… At least, if that would be a point exactly on the ellipse and not a false positive
- RPoint: Unused, compare strictRange with distance to point
- RPolyline: Only applied for non-perpendicular vectors towards limited line segments
- RXLine: Unused, handled as unlimited RLine
There is always a perpendicular vector towards an RXLine
- RRay: Unused for unlimited, not passed on for limited ⇒ RMAXDOUBLE
- RSpline: Undocumented for proxy, otherwise handled as RPolyline
- …

Turns out that for a returned valid vector one still has to verify that it is within range or not.
getDistanceTo is itself based on getVectorTo … Doing things twice.
Or that the projected point is on the limited shape … Also doing things twice.

Then I don't understand the purpose as it is only implemented for an RLine (segment) when limited. And then only when the projected position is not on the limited shape.
What requires an extra diversification on perpendicular or not.

I only see a purpose for RLine.getVectorTo(pos, false, 1e-6)
What is equally tolerant for the start and end of a limited line (segment).
Except that the magnitude from the start is always exactly zero, even when near.

Regards,
CVH

Heather theme has QTreeView::item:hover by default → Bug occurs
Dark theme has no QTreeView::item:hover → Normal behavior
Custom CSS with ONLY QTreeView::item:hover {} → Bug occurs

This did NOT occur in Qt5 production versions.

Reproduction Steps:
1. Apply Heather theme (contains QTreeView::item:hover by default)
2. OR: Apply any theme + add ONLY this CSS rule:

 QTreeView::item:hover {
 }

3. Restart QCAD as prompted after theme modification
4. Open layer list panel
5. Hover mouse over any layer item → Active layer immediately switches to hovered layer

Expected Behavior:
- Hover should only affect visual appearance
- Active layer should only change on explicit click selection
- Empty CSS rule "{}" should have no functional effect

Actual Behavior:
- Every layer becomes active as mouse hovers over it
- Affects ALL layers in layer list
- Property editor QTreeView and block list QTreeView are NOT affected

Workaround:
- Remove QTreeView::item:hover rule completely from CSS
- Use themes without QTreeView::item:hover (e.g., Dark theme)

Environment:
- QCAD: 3.32.9.0
- Qt: 6.11.0
- OS: Windows 11 25H2 (Build 26200.8328)
- Trigger: Heather theme OR any theme + QTreeView::item:hover CSS rule

Tested QCAD 3.32.8 on Ubuntu24.04 and MacOS10.10

Attached screenshots were taken using QT5 and QT6 for comparison (both at 125% scaling). Antialiasing was turned off. Note how the grid dots fade in and out like a moiré pattern.