Separate module into library and module

[rainman110]

Summary

My suggestion is, to separate the current code into a library (generic functionality without gtlab) and a module (requries gtlab).

Why is this refactoring required

Similar to QtNodes, other tools could use intelligraph. In particular, it makes the library easier to test and refactor, if we separate things.

How to refactor

Library:

• Nodes interface, basic nodes
• Execution engine
• Qt-based node graph renderer

Module:

• GTlab specific nodes
• Module implementation

[rainman110]

In GitLab by @mariusalexander on Apr 18, 2024, 09:10

What do you mean by "without GTlab"? Obviously we need GTlab for the GtObject which is the base object of all nodes for example. Please clarify @rainman110.

[rainman110]

DLR SC is evaluating, how we can use Intelligraphs as a CAD-GUI. They don't want to use GTlab though as a vehicle. Currently, the Intelligraph module is tied to GTlab and cannot be used without it.

IMHO, we should separate concers as e.g. done with the CADKernel (the library) and the Geometry Module (the module).

[rainman110]

I was though at the time of writing not aware, that nodes are GTObjects. So lets say, the data processor library can be used.

[rainman110]

In GitLab by @mariusalexander on Apr 18, 2024, 09:37

Hm I see your point, but I am not sure about it. It took a lot of time to integrate the library into the GTlab context and if we decouple the code now again we would introduce many interfaces to keep the functionality, especially if we can only have the dependency to the DataProcessor library.

• For example IntelliGraph is currently using GtObjectUI for the context menu in the graph editor, but also to access the node painter and node geometry.
• In addition we are also using the Application for the dark/bright mode and the predefined colors in GTlab.
• we use the undo/redo system, which would have to be reimplemented as well

[rainman110]

This should be a basis for discussion, hence the label. I'd like to have @real-ct-ac 's opinion as well.

I know, it is a lot of work. The benefit could be though, that we'll get some development work for free by SC.

Regarding your comments, it would be a lot of work to refactor this, but we can also use dependency inversion, to still use GTlab without directly linking against it. That would be the responsibility of the module then.

As I said, this is something we should discuss in the bigger round. There are both many benefits and downsides.

[mariusalexander]

I just wanted to note that now I am very much in favor of separating the modue into a standalone library and the module code itself.

As you have mentioned, ideally the library should not depend on GTlab. At the very least (or as a first start) it should only depend on the GTlab Dataprocessor and Logging (no GUI and Core dependency which should be quite doable). This would allow others to use the graph system without the ehole tech stack of the GTlab suite.

My idea would be to separate the basic graph system (no custom nodes, no module specific code, etc.) into its own repository. Then we could slowly remove the dependencies to GTlab (first GUI and Core then Dataprocessor etc). To avoid having to complicate the build process of the IntelliGraph module and all modules that depent on this module we could include the library repository as a submodule.

What do you think? @rainman110