martinitus/rs-plode

Trait definitions and implementation that help layouting and rendering graphs.

rs-plode's Issues

GitHub Actions

Would be nice to have a CI check for:

• Codestyle
• Running unittests

Bevore a PR can be merged.

`LayoutSequence` should have one handle on the graph.

Currently, a LayoutSequence is "an iterable of Layouts". This means, a LayoutSequence could eventually reference different graphs, because every layout has it's own handle on the graph it belongs to.

Instead, there should be one graph handle in the layout sequence.

Should `layout` and `animate` methods of Graph trait consume `self`?

rs-plode/src/lib.rs

Line 41 in a114c96

fn layout<'a, E: Engine>(&'a self, engine: E) -> E::Layout<'a, Self> {

Currently, the two mentioned methods take the graph by reference, which binds the lifetime of the returned layout structure to the lifetime of the graph.

This causes problems, if a user is mostly interested in the layout and does not want to manage the lifetime of the used graph explicitly. E.g. :

fn get_some_layout()->Layout<'a, SomeGraph>{
   let graph = SomeGraph::default();
   // This won't work, as layout is bound to lifetime of graph
   return graph.layout(SomeEngine{}); 
}

On the other hand, if the layout call consumes the graph, it will not be possible to create multiple layouts without cloning the graphs (also bad).

A solution should allow both, multiple layouts for the same graph and a way to avoid the lifetime bounds.