[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-edu-devel
Subject: Re: Rocs general graph layout implementation question.
From: Dilson_Guimarães <dilsonguim () gmail ! com>
Date: 2020-06-01 14:41:10
Message-ID: CAHw8pqwRZAhQW6He3PEMPdMmLxisZ0=njzvM9updMmT3WEiMfg () mail ! gmail ! com
[Download RAW message or body]
On Mon, Jun 1, 2020 at 10:40 AM Adriaan de Groot <groot@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=C3=A3es 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 insi=
de
> > 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 bea=
r
> 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 fin=
d
> 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 it=
s
> > 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 eve=
n
> have a tagged release.
>
This would make it hard to add it as a dependence. Right?
>
> [ade]
>
>
>
[Attachment #3 (text/html)]
<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>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic