<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jun 1, 2020 at 10:40 AM <span class="" style="" id=":dq.1" tabindex="-1">Adriaan</span> <span class="" style="" id=":dq.2" tabindex="-1">de</span> <span class="" style="" id=":dq.3" tabindex="-1">Groot</span> <<a href="mailto:groot@kde.org" target="_blank"><span class="" style="" id=":dq.4" tabindex="-1">groot</span>@<span class="" style="" id=":dq.5" tabindex="-1">kde</span>.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Dilson,<br>
<br>
I Have An Opinion. (I write that with caps to indicate that this is like Owl, <br>
in the Winnie-the-Pooh stories: someone who pretends to be very wise but <br>
doesn't have a handle on things at all; so this is just one thing you might <br>
consider)<br>
<br></blockquote><div><br></div><div>I appreciate opinions from who do not believe knowing everything even more!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On Monday, 1 June 2020 14:23:07 CEST Dilson Guimarães wrote:<br>
> I am a GSoC student working on the graph layout (drawing) capabilities of<br>
> Rocs <<a href="https://kde.org/applications/education/org.kde.rocs" rel="noreferrer" target="_blank">https://kde.org/applications/education/org.kde.rocs</a>>. I am going to<br>
> include graph layout algorithms to compute the positions for all the graph<br>
> vertices, satisfying some constraints such as keeping every vertex inside<br>
> the drawing area.<br>
<br>
Inside the *drawing* area. Oh. There's existing code with several variations <br>
to move a generated graph into a sensible location on the canvas, but bear in <br>
mind that the graph can be bigger than the viewport / drawing area.<br></blockquote><div><br></div><div>I saw parts of <span class="" style="" id=":dq.6" tabindex="-1">Rocs</span> 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 <span class="" style="" id=":dq.7" tabindex="-1">scrollbars</span> 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 <span class="" style="" id=":dq.8" tabindex="-1">scrollbars</span>.</div><div><br></div><div>Anyway, moving the whole graph while keeping the relative position of the <span class="" style="" id=":dq.9" tabindex="-1">vertices</span> is different from laying out the graph in way that considers the the <span class="" style="" id=":dq.10" tabindex="-1">viewport</span>. I expect the latter to generate more satisfactory results. <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> I have two options here: use an existing library to do<br>
> that or implement the algorithms directly. <br>
<br>
Re-use and re-cycle. I'd typically suggest using a library if the interface <br>
impedance isn't too large. However, ROCS is special: it's also an *example* <br>
and learning tool about graphs, and graph layout is something that might be <br>
interesting from that perspective. So consider doing it in Javascript (ugh?) <br>
so that it can be run through the interpreter in ROCS.<br>
<br></blockquote><div><br></div><div>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 <span class="" style="" id=":dq.11" tabindex="-1">Javacript</span> version just as an example to the user. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> The graph layout algorithms I would have to implement are optimization<br>
> algorithms, which I have some experience with because I do research on<br>
> optimization. A positive thing about implementing the algorithms myself is<br>
> that I would have more flexibility to make them better suited for Rocs.<br>
> Besides that, on future phases of this GSoC project, I will implement graph<br>
> layout algorithms for specific kinds of graph. For those, I did not find a<br>
> library ready for use.<br>
<br>
This suggests harder: do it yourself (maybe not in JS though)<br>
<br></blockquote><div><br></div><div>I am much more comfortable writing this in C++ than in Javascript. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> <br>
> On the other hand, going with the library can speed things up. I found one<br>
> library that seems to provide a good amount of functionality. Its name is<br>
> libcola <<a href="https://www.adaptagrams.org/documentation/libcola.html" rel="noreferrer" target="_blank">https://www.adaptagrams.org/documentation/libcola.html</a>> and its<br>
> GitHub repository can be found here<br>
> <<a href="https://github.com/mjwybrow/adaptagrams" rel="noreferrer" target="_blank">https://github.com/mjwybrow/adaptagrams</a>>. Maybe there are some issues<br>
> about adding more dependencies.<br>
<br>
adaptagrams itself does not look like it is packaged much; it doesn't even <br>
have a tagged release.<br></blockquote><div><br></div><div>This would make it hard to add it as a dependence. Right?<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
[ade]<br>
<br>
<br>
</blockquote></div></div>