Modernisation: Discussions

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
doia
Posts: 251
Joined: Sat May 29, 2021 5:47 am
Location: Düsseldorf

Re: Modernisation: Discussions

Post by doia »

In terms Modernization I also think of bringing the code layout/code separation/general architecture and the dependency of 3rd party libs to a current state.

Aside question: Is there anything like an overview over the FC code base regarding code separation and dependency between the single packages Base/App/Gui/Mod and to external libraries? I haven't found anything in the wiki, just an overview over the compile workflow https://wiki.freecadweb.org/Source_documentation and an overview over the relationship between core objects https://wiki.freecadweb.org/Part_Feature.
An example from the Blender code base is https://wiki.blender.org/wiki/Source/File_Structure and https://www.blender.org/bf/codelayout.jpg.

Currently I'm trying to understand the code base, the relationship between different modules and the call stack. I have the impression, that the different parts of the code could be more separated and external libs should be connected to the app in one place only (via an Adapter?).

Especially the QT libs are scattered throughout the code base and are included within the App/ parts although QT should only be used in Gui/ code. For example the src/Mod/Part/App code should not be allowed to call the QT Library, as it currently does for a QT_TRANSLATE_NOOP() functionality.

Here is a diagram of my current understanding of the source. Please correct me if I'm wrong.

Trying to understand the FreeCAD code structure.
Trying to understand the FreeCAD code structure.
FC_code structure.png (50.66 KiB) Viewed 1702 times
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Modernisation: Discussions

Post by wmayer »

Is there anything like an overview over the FC code base regarding code separation and dependency between the single packages Base/App/Gui/Mod and to external libraries?
I think there once was an image in the Wiki but not sure if it's still there. Anyway, in the codebase under Doc there is a FreeCAD.uml file that basically shows this:
FreeCAD.png
FreeCAD.png (38.3 KiB) Viewed 1673 times
Especially the QT libs are scattered throughout the code base and are included within the App/ parts although QT should only be used in Gui/ code.
From the image you can see that at the beginning it was designed like that and the reason was that Qt at that time was a monolithic library with mainly GUI functionality. However, with version 4 Qt has been split into many components and thus it's perfectly valid to use non-GUI stuff in App modules.

So, the image still shows the basic architecture with two exceptions:
  • App modules are allowed to use stuff from QtCore
  • The dependency of Mesh to OCC is not allowed any more (therefore MeshPart has been added)
FreddyFreddy
Posts: 176
Joined: Wed Mar 09, 2022 3:15 am
Location: Oz

Re: Modernisation: Discussions

Post by FreddyFreddy »

Plenty of these:

Code: Select all

Clang-Tidy: Default arguments on virtual or override methods are prohibited
I made one attempt to clean one up but was defeated. It seeems this will be a tedious one to clean up. I am assuming the warning is valid. 'Prohibited' is a strong word!
User avatar
doia
Posts: 251
Joined: Sat May 29, 2021 5:47 am
Location: Düsseldorf

Re: Modernisation: Discussions

Post by doia »

wmayer wrote: Wed May 04, 2022 9:14 am I think there once was an image in the Wiki but not sure if it's still there. Anyway, in the codebase under Doc there is a FreeCAD.uml file
Thank you. That's a good start. Maybe time to update this and link it to the Wiki. Will have a look into this.
App modules are allowed to use stuff from QtCore
OK, understood.

Though any implementation of QT_TRANSLATE_NOOP() within an App/ module should be moved to the Gui/ module, as it clearly is only Gui related. Here are the IMHO offending calls in src/Mod/Part/App/ (doing a simple search for a "Qt" string within the folder). Noteworthy that this only affects the FaceMaker feature within this module. Maybe time for a cleanup.

Code: Select all

src/Mod/Part/App/FaceMaker.cpp
  30,12: # include <QtGlobal>
  171,24:     return std::string(QT_TRANSLATE_NOOP("Part_FaceMaker","Simple"));
  176,24:     return std::string(QT_TRANSLATE_NOOP("Part_FaceMaker","Makes separate plane face from every wire independently. No support for holes; wires can be on different planes."));

src/Mod/Part/App/FaceMakerBullseye.cpp
  39,12: # include <QtGlobal>
  59,24:     return std::string(QT_TRANSLATE_NOOP("Part_FaceMaker","Bull's-eye facemaker"));
  64,24:     return std::string(QT_TRANSLATE_NOOP("Part_FaceMaker","Supports making planar faces with holes with islands."));

src/Mod/Part/App/FaceMakerCheese.cpp
  45,12: # include <QtGlobal>
  247,24:     return std::string(QT_TRANSLATE_NOOP("Part_FaceMaker","Cheese facemaker"));
  252,24:     return std::string(QT_TRANSLATE_NOOP("Part_FaceMaker","Supports making planar faces with holes, but no islands inside holes."));

src/Mod/Part/App/FeatureExtrusion.cpp
  339,24:     return std::string(QT_TRANSLATE_NOOP("Part_FaceMaker", "Part Extrude facemaker"));
  344,24:     return std::string(QT_TRANSLATE_NOOP("Part_FaceMaker", "Supports making faces with holes, does not support nesting."));

src/Mod/Part/App/PreCompiled.h
  66,4: // QT
  67,11: #include <QtGlobal>
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Modernisation: Discussions

Post by onekk »

wmayer wrote: Wed May 04, 2022 9:14 am
Is there anything like an overview over the FC code base regarding code separation and dependency between the single packages Base/App/Gui/Mod and to external libraries?
I think there once was an image in the Wiki but not sure if it's still there. Anyway, in the codebase under Doc there is a FreeCAD.uml file that basically shows this:
FreeCAD.png

...
So, the image still shows the basic architecture with two exceptions:
  • App modules are allowed to use stuff from QtCore
  • The dependency of Mesh to OCC is not allowed any more (therefore MeshPart has been added)
From that image is not clear actual position of OCCT.

One of the basic concern when you start to try to know something about FC is the way things are related, in some old thread, I have made some "very wrong assumptions" on "how things are done" when visualizing things, (roughly the relation about Coin3D and OCCT).

One of the future improvement maybe could be to "make some efforts" to explain some "basic internals", like:

- what happen when you create a new DocumentObject, or a TopoShape (that has no Gui onbject to show)
- what happen when you load a FCStd file (and when you save a Document to disk)

Not a very detailed informations, but a rough explain of the interaction between libraries, a surely wrong example:

- A new DocumentObject is created (FC)
- A new shape is created (OCCT)
- OCCT pass a mesh to Coin3D
- Coin3D will show the mesh on the 3d view
- The DocumentObject is added to the treeview

At least try to catch the complex work that happen behind the scenes.

Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
wmayer
Founder
Posts: 20241
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Modernisation: Discussions

Post by wmayer »

Though any implementation of QT_TRANSLATE_NOOP() within an App/ module should be moved to the Gui/ module, as it clearly is only Gui related.
The QT_TRANSLATE_NOOP only marks a string for translation so that Qt's lupdate will add it to the .ts files. But you get the translated text only when using the function qApp->translate() or tr().

A translated string can be shown in the GUI when a thrown exception is handled as otherwise only the English text is shown and a user probably won't understand what has happened.

Example:

Code: Select all

void Function_in_Gui()
{
    try {
    ...
        // call a function from app
        function_in_App(); // raises an exception whose text is marked for translation
    }
    catch (const Exception& e) {
        QMessageBox::warning(this, "Failure", qApp->translate("Context", e.what()); // the translated text is used here
    }
}
I don't see why this should be a problem.
Noteworthy that this only affects the FaceMaker feature within this module. Maybe time for a cleanup.
As far as I can see the functions getUserFriendlyName() or getBriefExplanation() are nowhere used in GUI. Thus, marking the strings for translation seems to be superfluous.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Modernisation: Discussions

Post by adrianinsaval »

onekk wrote: Thu May 05, 2022 10:42 am From that image is not clear actual position of OCCT.
I think several of the Std modules depend on OCCT but not the core system. I would assume they make a similar diagram as the Mesh module does there with separate App and GUI portions.
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: Modernisation: Discussions

Post by onekk »

adrianinsaval wrote: Thu May 05, 2022 2:15 pm I think several of the Std modules depend on OCCT but not the core system. I would assume they make a similar diagram as the Mesh module does there with separate App and GUI portions.
but not the core system
In what sense, I was thinking that the "core" of CAD program was his "modelling engine", If FC would be able to start without checking for the presence of OCCT I will be surprised.

More probably I have totally misunderstood your comment. please explain me the sense.

Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Modernisation: Discussions

Post by adrianinsaval »

Look at the diagram, the "core system" is the app itself and the gui, doesn't include any of the actual modelling stuff, those are primarily in the Part module and a lot of the rest base their stuff in the Part module and some make direct calls to OCCT. I would have to check but my understanding of this is that you wont find anything OCCT related in src/App and src/Gui directories for example but only on src/Mod/* and presumably not all modules use OCCT
FreddyFreddy
Posts: 176
Joined: Wed Mar 09, 2022 3:15 am
Location: Oz

Re: Modernisation: Discussions

Post by FreddyFreddy »

IDE reports loads of:

Code: Select all

Function xxx is never used
E.g. App/DocumentObserverPython.h has 21 of these.

Given my ignorance, I ask if these:
a) are genuine. Abandoned, or just good ideas but unused (so should not be there in the first place)
b) exist for some other mechanism (eg Python?)
c) shoud be ignored. (e.g. some funny c++ thing I don't yet know about?)
Post Reply