No subject

willing to implement, either in KGraphViewer itself or in a new
library (if you don't want these changes or maybe if these changes
would require a complete re-write).

--- Important wishes: ---

* Allow in-memory graphs
If I understand it correctly, graphs must be loaded from files.
I think a class should be provided to let the programmer construct the
graph structure, without the associated serialization/disk/parsing
overhead.
See the example code in the next wish.

* Implement MVC "better" (IMHO)
When using KGraphViewer as a widget, it acts both as a View and as a Model.
I think the user should use two separate classes: DotGraphView as View
and DotGraph as model.
This is currently not possible because the DotGraph interface is not
exposed to user code and because DotGraphView contains a DotGraph
instead of referencing an independent DotGraph provided by the user. I
imagine code like this (after the relevant "using" declarations):

DotGraph *graph = new DotGraph(DotGraph::Directed);
Node* a = graph->addNode("A");
Node* b = graph->addNode("B");
graph->addEdge(a, b);

DotGraphView *graphView = new DotGraphView();
graphView->setGraph(graph);
myLayout->addWidget(graphView);

// The "A -> B" graph is drawn

graph->addEdge(b, a);

// The model notifies the view of this change, and the widget is
updated accordingly.

* Incremental layouts
A simple change (for example, adding a node) should not require a full
recalculation of the layout, and should usually have a limited amount
of changes in the layout. I think this can be addressed using
Dynagraph instead of Graphviz.


--- Optional wishes: ---

* Animations on graph changes
When the graph is changed, for example by adding a new edge, firstly a
straight new edge should appear, and then the nodes and edges should
move from the old positions to the updated ones (the new edge starts
as a straight line and moves to its position).

* Polishing of the widget interface
I think (but being a noob, I may be wrong) that when using
KGraphViewer as a widget instead of a KPart, it should have a
constructor that doesn't take a KActionCollection. Maybe it should
even have a default (no argument) constructor.

* Allow widgets as nodes
This is maybe the most complicated wish, and it is *really* optional.
I think some applications might want to use custom-drawn widgets as
nodes. For example, I imagine the elements of an UML diagram, lay out
by Dynagraph as rectangular boxes and then filled with the widget's
content.


Am I wrong? I.e., are some of my wishes already implemented?

Do you think I should implement these changes in KGraphViewer?
If this is the case, should I develop in a separate branch or something? How?
This would be my first contribution to a KDE project.

Thanks,
Marco Poletti