Right now, if I want to fill an area with a hatch pattern, I have to select all the enclosing objects (lines, arcs) and then I can select the hatch tool. That can be under some circumstances a tedious task.
To illustrate this, I created a simple example (see Attachment 1: Hatching.png).

Step 1: Create a rectangle.
Step 2: Draw four vertical lines.
Step 3: Select the four lines surrounding the first area. –> Problem! The horizontal lines are too long.
Step 4: Divide the long horizontal lines of the rectangle where the vertical lines touch. Now the lines surrounding the three areas can be selected.
Step 5: Hatch the selection. Done.

Just for fun try recreating my second example (see Attachment 2: Hatching2.png)

Therefore I would like to suggest a far more simple approach.

Step 1: Select the Hatch Tool.
Step 2: Click inside the area you would like to be hatched. Done.

Of course that would mean that the hatch style is already pre-defined and can be changed later, if needed.

In this way productivity can be increased by … [fill in you own estimate] … times.

Example 2 would need only 13 clicks to hatch all the areas (including the hatch tool button).

When selecting an object to create a library item it keeps prompting for the start after saving, this appears to be a continuous loop.
It still saves the file but I need to escape out of loop to cancel.

Linux Mint 2.3

Cheers
John
Version:
3.33.1.0 (3.33.1)
Internet:
QCAD.org
Build Date:
Sep 8 2026
Revision:
897079c
Qt Version:
6.11.0
Architecture:
x86_64
Compiler:
gcc 11.4.0

I just noticed this today.

When I select a layer to make it current, then move my mouse back onto the canvas to start drawing, the pencil pointer follows the cursor. As a result, the wrong layer is used instead of the one I thought I had selected.

I hope that makes sense.

Interestingly, this doesn’t happen in the Community Edition.

Gif attached..

Cheers,
John

Operating system: Linux Mint 22.3 Cinnamon
QCAD/CAM version: 3.33.1 Professional, Linux Qt6 x86_64

Andrew,

Regarding: Forum topic 12045
Trying to replicate the problem reported by user 'Leno'.

With a selection and for an action that expects a coordinate input,
with snap mode selection (SK)
there are no snapping points displayed to select from.

Expecting 10 reference markers in color #0040c8 by default.

Changes were made around Jun 5, 2026
Snap/SnapSelectionCenter → Snap/SnapSelection

Also troubled by the associated note in EAction Line 287 Commit 4d3a6e5

The note states that the zoom state is set to auto.
But it is the document interface snap mode that is (re-)set to auto on resuming.

Regards,
CVH

For a point coinciding with the center, getAngleTo() at line 788 returns zero by default.
For an arc starting at, ending at or spanning over orientation zero
(verified and not excluded by line 789-791)
the method returns a defined point on the arc at zero rads.

Analog to RCircle::getVectorTo there are infinite solutions and thus none well defined.

The RCircle method excludes a point at the center and returns an invalid RVector.
… However:
Comparing the SquaredMagnitude() with 1e-18 is fundamentally incorrect (FS#2741)
Correctly squaring both sides of (|d - v| < tol) results in: ((d - v)² < tol²)
And this expands to: (d² - 2dv + v² < tol²) where one still needs to know the magnitude.

… Additionally:
getAngleTo() returns zero by default when the two points are 1e-6 units or less apart.
A factor thousand times larger than RS.PointTolerance.
This can still result in a defined point on the arc at zero rads for
points at a distance between 1e-9 to 1e-6 from the center.

As like all getVectorTo() methods it is a key resource.
RArc::getClosestPointOnShape() can for example return a false solution.

Fixing this may for example break InfoDistanceEP.prototype.pickCoordinate or RSnapPerpendicular::snapEntity …
… Only if you manage to indicate really near the center of an arbitrary arc.

Then RSnapPerpendicular::snapEntity has no solution for a circle and its center.
But it has a solution at zero rads for an arc.

Regards,
CVH