Separate module into library and module

dlr-gtlab / intelligraph-module

A Node-based Workflow Engine for GTlab

0 stars 0 forks source link

Separate module into library and module #90

Open rainman110 opened 5 months ago

rainman110 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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.
Only we use the undo/redo system, which would have to be reimplemented as well

rainman110 commented 5 months ago

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.