Page 3 of 9

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Mon Nov 25, 2019 10:13 am
by Zolko
kkremitzki wrote:
Wed Nov 20, 2019 6:43 am
For reference, the Debian Import Freeze for Ubuntu 20.04, the next long-term support release, is February 27th
wmayer wrote:
Wed Nov 20, 2019 6:43 pm
But when we really try to make a release in early 2020 then no major change can be merged any more after around mid of December or so.
Considering the experience with Assembly4, there have not been any major changes to App::Link since the addition of the ExpressionEngine some months back. There was a bug about absolute/relative file paths that was fixed, there are probably some left, but there don't seem to be any new features needed from core FreeCAD (App::Part and App::Link) for the Assembly4 workbench. That is, nothing that couldn't be handled from Python.

There was my feature request for variant links, but I think that I'll try to do that with a scripted Python object. And if not, then it can wait for v0.20

So from the Assembly4 viewpoint, the current v0.19 version of FreeCAD is very good, there won't be any feature requests to core FreeCAD, and I also vote to aim for a v0.19 release for the next Ubuntu LTS.

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Mon Nov 25, 2019 10:51 pm
by vocx
Zolko wrote:
Mon Nov 25, 2019 10:13 am
Considering the experience with Assembly4, there have not been any major changes to App::Link since the addition of the ExpressionEngine some months back. There was a bug about absolute/relative file paths that was fixed, there are probably some left, but there don't seem to be any new features needed from core FreeCAD (App::Part and App::Link) for the Assembly4 workbench. ...
What Werner says mostly applies to realthunder, because even if there aren't major changes to App::Link or the Expression Engine themselves, realthunder is still pushing a bunch of changes and bug fixes to the code, for example, the latest of which is PR #2723: Plain/Geo group behavior change and related 3D visualization/selection enhancement.

This basically adds App::LinkGroup to App::Part, to support App::Links better. Would this require yet another update of Assembly4?

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Tue Nov 26, 2019 12:08 pm
by Zolko
vocx wrote:
Mon Nov 25, 2019 10:51 pm
realthunder is still pushing a bunch of changes and bug fixes to the code, for example, the latest of which is PR #2723: Plain/Geo group behavior change and related 3D visualization/selection enhancement.
Going through this list, I have 2 comments:

  • There is a change in plain group visibility toggling behavior. Previously, when a group is hidden, all its (nested) children are hidden by changing the 'Visibility' property of all of them. This is still the same, but the plain group will remember its children visibility before toggling, and will restore the children visibility when the group is shown again.
This corrects a very annoying bug, that is described here. Assembly4 has a workaround, but if this is not merged all other users of App::Link will be hit by this.

  • Another change is that App::Part (OriginGroupExtension) no longer creates origin features by default. This saves six objects per container, which is rather significant for STEP import with large amount of small assemblies, where the majority of the imported container will never need to use the origin feature. To initialize the origin features, simply toggle the visibility of the Origin group
I never liked this "Origin" thing, so I won't complain if it goes away. Actually, I don't understand why it's even there: why not use Datum Planes, like all other CAD systems in the world do ? The Origin things are similar to Datum Planes and Axes, but inferior in every aspect (you cannot create new ones, so if you want new planes to draw sketches you need to create Datum Planes anyway).

Speaking of Datum objects, today they are from the PartDesign workbench, and belong to the PartDesign:: namespace (please forgive me if it's not the correct technical term). When they are used in a Part container however that leads to warnings in the Report View:

Code: Select all

PartDesign::CoordinateSystem / LCS_1: Links go out of the allowed scope
PartDesign::Plane / DatumPlane: Links go out of the allowed scope
They work perfectly well, do exactly what one would want them to do, they're reliable and I have yet to see 1 occasion when this fails, but still FreeCAD complains with this scary warning message.

So, at minimum, could this useless warning message please be removed ?

Even better, and that's why I write it here, these datum object are in PartDesign for historical reasons, but they would be much better served if they were in the Part namespace, usable directly in App::Part objects. And, hence, also in PartDesign, of course.

Thus, App::Part, App::Link and Part::DatumObjects would form the fundamental building blocks and plumbing interfaces for all FreeCAD assemblies. New solvers could be implemented to solve particular usecases, and if all FreeCAD assemblies use the same assembly data structure they could be compatible. I could very well imagine that architectural, civil engineering, free-form, mechanical engineering, optical engineering, FEM ... problems would need specialized solvers. Assembly4 with the ExpressionEngine would only be one of them. All a solver actually does is to calculate the App::Placement property of an object. It would be a huge gain for FreeCAD users if they all could share the same assembly data structure independently from the solver.

Since v0.19 introduces a new interface anyway (App::Link), now would be a good time to move datum objects from PartDesign namespace to Part namespace. Few FreeCAD users are using PartDesign::CoordinateSystems until now, so few would be affected, and they would "easily" understand that some interfaces have changed with the major upgrade of v0.19. For backwards compatibility, when opening an old FreeCAD file (v<0.19), each time a PartDesign::Plane is encountered it is interpreted as Part::DatumPlane and saved as such the next time. Easy.

I know that that would break quite some stuff, but it's better now than for v0.20. As I said earlier, it's not an Assembly4 request because it works very well like that, it's more a long-term investment request, such that the FreeCAD data format can be defined for the very long term: if the FreeCAD data structure stabilises it is reasonable to aim for a stable 1.0 release. It will cause some short-term pain, but with a huge long-term gain.

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Tue Nov 26, 2019 12:30 pm
by triplus
The way i see it is, this was a multi year effort, but finally we can say FreeCAD 0.19 should be App::Link enabled. Effort similar to PartDesign NEXT, where things can get a bit messy, and it is hard to do them involving "low impact" approach. In my opinion it makes sense, to finish all the App::Link related (detected) issues, and implement all the planned functionality. If that comes down to FreeCAD 0.19 missing the Ubuntu 20.04 window, too bad, but there is a PPA, therefore not such a big deal. Holiday season is coming, and we can't expect developers to focus only on FreeCAD during it! ;)

@wmayer said, there is still much work left to do, to keep upstream in good condition, a few A4 sheets of todo items, after the App::Link merge, and @realthunder would still like to introduce a feature or two, such as App::LinkGroup. @realthunder are there any other App::Link related plans from your side, targeted at FreeCAD 0.19 development cycle? Best to do that in FreeCAD 0.19 development cycle and after to go for FreeCAD 1.0. Assembly 2, Assembly 3, Assembly 4, assembly solver:

https://forum.freecadweb.org/viewtopic.php?f=20&t=40525

We are finally there, and best not to start the new development cycle with an App::Link effort, again.

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Tue Nov 26, 2019 8:24 pm
by kkremitzki
From a package maintenance perspective not making the 20.04 release is fine, I was just about to try to upload an early version of 0.19 to get ahead of the NEW queue wait. If it doesn't look like that target will be hit I can just upload to the Debian Experimental to make sure a 0.19 pre-release doesn't end up in Ubuntu.

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Tue Nov 26, 2019 9:37 pm
by triplus
It would be nice, Ubuntu 20.04 being a LTS release. I guess it comes down to App::LinkGroup and decision if it should be a part of the FreeCAD 0.19 release, or not. If yes, somehow i feel the release won't happen before April 2020.

P.S. Best to wait and see, on how things will evolve in the following few weeks.

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Tue Nov 26, 2019 9:54 pm
by sgrogan
kkremitzki wrote:
Tue Nov 26, 2019 8:24 pm
From a package maintenance perspective
Do you know the PY3/OCCT/QT versions that are being targeted? (For Debian)

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Tue Nov 26, 2019 10:02 pm
by Kunda1

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Tue Dec 17, 2019 11:22 pm
by sgrogan
But when we really try to make a release in early 2020 then no major change can be merged any more after around mid of December or so. I am just saying because it also was in the discussion that realthunder's topo naming implementation may find its way into v0.19.
So, what do we think?

Re: [Discussion] Preparing for the upcoming v0.19 release

Posted: Thu Dec 19, 2019 3:40 pm
by Kunda1
December 19th.. Time for feature freeze?
Start focusing on bugs, documentation, translations etc...?