<div dir="ltr"><div dir="ltr">Thank you for your input.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 7, 2020 at 2:31 PM Andreas Cord-<span class="" style="" id=":1j0.1" tabindex="-1">Landwehr</span> <<span class="" style="" id=":1j0.2" tabindex="-1">cordlandwehr</span>@<span class="" style="" id=":1j0.3" tabindex="-1">kde</span>.org> 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">On Montag, 1. Juni 2020 14:23:07 CEST Dilson Guimarães wrote:<br>
> Hello,<br>
> <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. I have two options here: use an existing library to do<br>
> that or implement the algorithms directly. Because I am new here, I thought<br>
> it would be a good idea to ask for your opinion. What option do you think<br>
> is more appropriate? Even if there is no clear answer, I would like get<br>
> your opinion about the pros and cons of each option. I am providing more<br>
> information about each option below.<br>
> <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>
> 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>
Hi Dilson and thank you very much for your work on Rocs! And also thanks for <br>
this interesting question :)<br>
<br>
I am trying to look from a user story point of view at the problem and I can <br>
imagine the following user stories (not all of them might be important and <br>
some might even be out of scope). What comes into my mind are the following <br>
possible desires by our users:<br>
- As a user, I want to transform my graph such that it is easier to understand <br>
because I manually analyze the graph with my eyes (this could mean for <br>
example: minimizing number of crossed edges, moving nodes closer together; I <br>
am not sure if this means that everything should be on the visible area <br>
because there should be zooming options)<br></blockquote><div><br></div><div>You are right. Having everything visible is not always desirable and, sometimes, it is impossible. Currently, <span class="" style="" id=":1j0.4" tabindex="-1">Rocs</span> use scroll bars to solve this problem.</div><div><br></div><div> The current version of the graph layout <span class="" style="" id=":1j0.5" tabindex="-1">plugin</span> I am developing allows the user to control some parameters of the algorithm in order to customize  the layout. However, the level of control is very limited. Some criteria such as the emphasis on reducing the number of crosses between edges and spreading nodes as evenly as possible  are not represented yet, because the current algorithm does not support them directly. Once I add an algorithm that does, I am thinking about having an user interface that lets the user choose the emphasis of the algorithm. <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">
- As a user, I want to transform my graph into a certain format (e.g. a ring) <br>
because it is an established layout in my community (I know P2P researchers, <br>
who usually look at ring graphs; this could still mean that e.g. the number of <br>
crossing edges shall be minimized).<br></blockquote><div><br></div><div>It is not easy to define what makes a graph layout good. Worse than that, this definition changes from one use case to the other. Getting some guidance from the user can help <span class="" style="" id=":1j0.6" tabindex="-1">Rocs</span> produce layouts that fulfills the needs of the user. I am going to try to find a way to get such guidance without having to support each "format" separately. <br></div></div><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- As a user, I want to run my own graph transformation algorithm because I am <br>
doing research in the graph drawing field (this might be already possible, but <br>
it is a very different use case from the above ones).<br>
<br></blockquote><div><br></div><div>I think this is already possible. Thanks to the comments given by <span class="" style="" id=":1j0.7" tabindex="-1">Adriaan</span> <span class="" style="" id=":1j0.8" tabindex="-1">de</span> <span class="" style="" id=":1j0.9" tabindex="-1">Groot</span>, I am considering creating an example implementation of a layout algorithm in JavaScript. This would be more useful for those learning layout algorithms and those trying to run their own.<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">
Regarding the use of third party libraries. It is much preferred if we stick <br>
to packaged libraries, which are at least available on OpenSuse (because our <br>
CI system is running there) and Debian, because it covers another big part of <br>
the Linux universe. But if it is a good library and we really want to use it <br>
because it helps us a lot, we should talk to packagers if we can make it <br>
available. -- Yet dependencies always come with a cost for maintenance... If <br>
it is only a simple self-contained layouting algorithm, it also might be an <br>
option to only use their algorithm code and integrate it into Rocs (the LGPL <br>
license of that library would allow it).<br></blockquote><div><br></div><div>Thank you for the explanation. For now, I decided to go with my own implementation. I found out that I will have to customize some details and parameters of the algorithm to achieve layouts that look nice. Although some libraries can be customized in some ways, I think it is easier to do in my own implementation</div><div> </div><div><br></div><div>Best regards,</div><div>Dilson Guimarães.<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>
Cheers,<br>
Andreas<br>
<br>
<br>
</blockquote></div></div>