FreeCAD News

WIP Wednesday, 12 November 2025

Published by

Aleksandr Prokudin

on

This week in FreeCAD development:

Sketch­er:

  • Rexbas fixed a crash by remov­ing unused UI icons (PR#25162).
  • tetek­toza fixed a bug that result­ed in delet­ing hid­den ele­ments (PR#25010).
  • Pad­dle­Stroke fixed the ori­gin axis and planes indi­ca­tor shown when edit­ing sketch­es (PR#20727).

Tech­Draw:

  • theo-vt patched the code to ensure the autodis­trib­ute para­me­ter is con­sis­tent when going from a pro­jec­tion group to a view and back to a pro­jec­tion group in TaskPro­j­Group (PR#25103).
  • Rexbas fixed Tech­Draw ignor­ing the “Zoom at Cur­sor” set­ting in Pref­er­ences (PR#25160).

BIM/Draft: 

  • Roy-043 fixed the bug where an emp­ty human fig­ure (for scale) would be cre­at­ed (PR#25186).
  • Paullee0 fixed an issue in Arch­Stairs (PR#25167).

FEM:

  • NewJok­er changed cat­e­gories of two FEM exam­ples (PR#25246) and added a ccx capac­i­tance two spheres exam­ple (PR#25117).
  • marioalexis84 fixed Capac­i­tance­Body default val­ue (PR#25148).

CAM:

  • Con­nor fixed a crash when the tool­bit object has been delet­ed or is miss­ing (PR#25228). He also fixed an infi­nite recom­pute loop when Tool­Bit prop­er­ties use expres­sions (PR#25039).
  • freck­le­tonj wrote a pre­lim­i­nary patch for a bug that affect­ed CAM jobs (PR#25034).
  • tarman3 fixed the Slot task panel.

Oth­er changes:

  • Var­i­ous small GUI fix­es, crash fix­es, and improve­ments by kadet1090 and chennes.
  • depthof­fo­cus fixed a release block­er where FreeCAD was not offer­ing to save mod­i­fied files on quit­ting the pro­gram (PR#24876).
  • pjcreath fixed a few crash­es in the mea­sur­ing tool after an undo (FPR#35129).

Addi­tion­al improve­ments and fix­es were con­tributed by FlachyJoe, kadet1090, Pad­dleS­gtroke, mar­bocub, ipatch, pyro9, chennes, marioalexis84, and NewJoker.

If you are inter­est­ed in test­ing the lat­est week­ly build, you can grab it here.

PR stats: since the pre­vi­ous report, 35 pull requests have been merged, and 47 new pull requests have been opened.

Issue stats: over­all, there are 3049 open issues in the track­er, up by 17 from last week. There are 5 release block­ers cur­rent­ly, down by 4 from last week. The list of block­ers is revis­it­ed and updat­ed on Mon­day merge meetings.

We merged a sub­stan­tial­ly large patch that refor­mats the source code. So we are wait­ing to see what bugs it spawns before cut­ting the release candidate

Discover more from FreeCAD News

Subscribe to get the latest posts sent to your email.

One response to “WIP Wednesday, 12 November 2025”

  1. Usuario Avatar
    Usuario

    Hel­lo,

    In a pre­vi­ous post on the FreeCAD blog, I men­tioned an issue with the Fil­let tool. The response I received was: “It’s a very well known issue that requires a com­plex fix in the Open­Cas­cade engine.”
    I do not know what would be required to imple­ment a defin­i­tive solu­tion; how­ev­er, I would respect­ful­ly sug­gest con­sid­er­ing a workaround that could avoid or mit­i­gate this behavior.

    Below is a con­cise descrip­tion of the problem:

    When apply­ing the Fil­let tool simul­ta­ne­ous­ly to two oppo­site edges of a face, sep­a­rat­ed by a dis­tance X, I fol­low these steps:

    Select the Fil­let tool.

    Select the two edges to be filleted.

    Assign the fil­let radius (either direct­ly or by adjust­ing the default value).

    When a radius val­ue dif­fer­ent from the aver­age dis­tance between the edges is assigned, two out­comes occur:

    If the radius is small­er than the aver­age dis­tance between the edges, the oper­a­tion com­pletes with­out issue.

    If the radius is greater than the aver­age dis­tance between the edges, the fil­let oper­a­tion exe­cutes, but the geom­e­try breaks (incor­rect fillet).

    When the radius is exact­ly equal to the aver­age dis­tance between the edges, the mes­sage “Input error, BRep_API com­mand not done” appears and the oper­a­tion does not execute.

    When adjust­ing the radius incre­men­tal­ly, the result­ing edges and fil­lets are dis­played in magen­ta, except when the val­ue match­es the aver­age dis­tance, in which case they are dis­played in red.
    If OK is pressed when the radius dif­fers from the aver­age, the oper­a­tion com­pletes, even if it may not be geo­met­ri­cal­ly valid. If OK is pressed when the radius equals the aver­age, the fil­let does not execute.

    I con­sid­er that, in any case—whether the radius is assigned direct­ly or incrementally—when it is greater (not just equal) than the aver­age dis­tance between the edges, the oper­a­tion should not be allowed to execute.

    Thank you for reading.

    Best regards.

Recent posts

Discover more from FreeCAD News

Subscribe now to keep reading and get access to the full archive.

Continue reading