Rocs general graph layout implementation question.

[Dilson Guimarães]

On Mon, Jun 1, 2020 at 10:40 AM Adriaan de Groot <groot at kde.org> wrote:

> Hi Dilson,
>
> I Have An Opinion. (I write that with caps to indicate that this is like
> Owl,
> in the Winnie-the-Pooh stories: someone who pretends to be very wise but
> doesn't have a handle on things at all; so this is just one thing you
> might
> consider)
>
>
I appreciate opinions from who do not believe knowing everything even more!


> On Monday, 1 June 2020 14:23:07 CEST Dilson Guimarães wrote:
> > I am a GSoC student working on the graph layout (drawing) capabilities of
> > Rocs <https://kde.org/applications/education/org.kde.rocs>. I am going
> to
> > include graph layout algorithms to compute the positions for all the
> graph
> > vertices, satisfying some constraints such as keeping every vertex inside
> > the drawing area.
>
> Inside the *drawing* area. Oh. There's existing code with several
> variations
> to move a generated graph into a sensible location on the canvas, but bear
> in
> mind that the graph can be bigger than the viewport / drawing area.
>

I saw parts of Rocs code that try to do exactly that. However, I still
experience some issues with nodes that do not appear (and I can not use the
scrollbars to make then completely visible). For bigger graphs, I am
assuming that it is possible to draw them in such a way that it is possible
to view everything by using the scrollbars.

Anyway, moving the whole graph while keeping the relative position of the
vertices is different from laying out the graph in way that considers the
the viewport. I expect the latter to generate more satisfactory results.



>
> > I have two options here: use an existing library to do
> > that or implement the algorithms directly.
>
> Re-use and re-cycle. I'd typically suggest using a library if the
> interface
> impedance isn't too large. However, ROCS is special: it's also an
> *example*
> and learning tool about graphs, and graph layout is something that might
> be
> interesting from that perspective. So consider doing it in Javascript
> (ugh?)
> so that it can be run through the interpreter in ROCS.
>
>
I love the idea of having a Javascript implementation of a graph layout
algorithm. However, because the idea is to have the layout functionality
built-in, I think that dealing with the interpreter and making everything
integrate well would add unnecessary complexity.  I would prefer to add a
separate Javacript version just as an example to the user.


>
> > The graph layout algorithms I would have to implement are optimization
> > algorithms, which I have some experience with because I do research on
> > optimization. A positive thing about implementing the algorithms myself
> is
> > that I would have more flexibility to make them better suited for Rocs.
> > Besides that, on future phases of this GSoC project, I will implement
> graph
> > layout algorithms for specific kinds of graph. For those, I did not find
> a
> > library ready for use.
>
> This suggests harder: do it yourself (maybe not in JS though)
>
>
I am much more comfortable writing this in C++ than in Javascript.


> >
> > On the other hand, going with the library can speed things up. I found
> one
> > library that seems to provide a good amount of functionality. Its name is
> > libcola <https://www.adaptagrams.org/documentation/libcola.html> and its
> > GitHub repository can be found here
> > <https://github.com/mjwybrow/adaptagrams>. Maybe there are some issues
> > about adding more dependencies.
>
> adaptagrams itself does not look like it is packaged much; it doesn't even
> have a tagged release.
>

This would make it hard to add it as a dependence. Right?

>
> [ade]
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-edu/attachments/20200601/7e7317ad/attachment.htm>