[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-extra-gear
Subject: Re: [Kde-extra-gear] KGraphViewer ideas ...
From: Sandro Andrade <sandro.andrade () gmail ! com>
Date: 2009-06-17 13:05:05
Message-ID: b3dbd38b0906170605r762ee6afgb733b739ccfa7736 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Hi Ga=EBl,
At the beginning, it was only a pure visualization tool, but it appeared
> that
> interactions were needed (to support actions, changes during graph life
> time,
> etc). And then I started to add editing features. But, you're right view
> and
> edit features could be separated.
Ok !
> > 2) Can I implement, in the application, the code to be executed when a
> > graph node is clicked or has a mouse over event ? Again, wouldn't the
> > kpart have its reuse improved if such interaction features were not
> > pre-defined ?
> They aren't! They are just signals that you can connect to to handle
> actions.
> Also, when you want to act on a graph element, you use slots to send it
> messages.
> When you click on a node, the selectionIs signal is sent.
> The part is missing hovering signals, though.
Ok, I'll try connect such signals to slots in my KDevelop plugin.
BTW, in the attached image you can see some preliminary result on control
flow graphs inside KDevelop using the KGraphViewer kpart.
> >
> > 3) Why haven't you used Graphviz as a library (as indicated in
> > http://www.graphviz.org/pdf/libguide.pdf) instead of relying in
> > QProcess invocation of dot, twopi and output processing (I know, this
> > is the KCachegrind approach) ?
> You said it: it's the kcachegrind approach and in fact, when I started
> kgraphviewer I reused the kcachegrind code :-) Well, there is not much
> remaining up to now.
> I think it is still a good solution. The xdot format is easy to parse. Bu=
t
> I
> already thinked to have a look at the graphviz library.
I'm using Graphviz programmatically to construct the graph from the functio=
n
calls collected in the source code. It's API is quite ease and complete.
Thanks,
- -
Sandro Santos Andrade
--------------------------------------------------------
Distributed Systems Laboratory (LaSiD)
Computer Science Department (DCC)
Federal University of Bahia
Brazil
[Attachment #5 (text/html)]
Hi Gaël,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" \
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; \
padding-left: 1ex;">At the beginning, it was only a pure visualization tool, but it \
appeared that<br>
interactions were needed (to support actions, changes during graph life time,<br>
etc). And then I started to add editing features. But, you're right view and<br>
edit features could be separated.</blockquote><div><br>Ok !<br> </div><blockquote \
class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt \
0pt 0.8ex; padding-left: 1ex;"><div class="im"> > 2) Can I implement, in the \
application, the code to be executed when a<br> > graph node is clicked or has a \
mouse over event ? Again, wouldn't the<br> > kpart have its reuse improved if \
such interaction features were not<br> > pre-defined ?<br>
</div>They aren't! They are just signals that you can connect to to handle \
actions.<br> Also, when you want to act on a graph element, you use slots to send \
it<br> messages.<br>
When you click on a node, the selectionIs signal is sent.<br>
The part is missing hovering signals, though.</blockquote><div><br>Ok, I'll try \
connect such signals to slots in my KDevelop plugin.<br>BTW, in the attached image \
you can see some preliminary result on control flow graphs inside KDevelop using the \
KGraphViewer kpart.<br> </div><blockquote class="gmail_quote" style="border-left: \
1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div \
class="im"> ><br>
> 3) Why haven't you used Graphviz as a library (as indicated in<br>
> <a href="http://www.graphviz.org/pdf/libguide.pdf" \
target="_blank">http://www.graphviz.org/pdf/libguide.pdf</a>) instead of relying \
in<br> > QProcess invocation of dot, twopi and output processing (I know, this<br>
> is the KCachegrind approach) ?<br>
</div>You said it: it's the kcachegrind approach and in fact, when I started<br>
kgraphviewer I reused the kcachegrind code :-) Well, there is not much<br>
remaining up to now.<br>
I think it is still a good solution. The xdot format is easy to parse. But I<br>
already thinked to have a look at the graphviz library.</blockquote><div><br>I'm \
using Graphviz programmatically to construct the graph from the function calls \
collected in the source code. It's API is quite ease and complete.<br> \
<br>Thanks,<br></div></div>- -<br>Sandro Santos \
Andrade<br>--------------------------------------------------------<br>Distributed \
Systems Laboratory (LaSiD)<br>Computer Science Department (DCC)<br>Federal University \
of Bahia<br> Brazil<br>
--001e680f12eca0e4a8046c8af000--
["controlflowgraph.png" (image/png)]
_______________________________________________
Kde-extra-gear mailing list
Kde-extra-gear@kde.org
https://mail.kde.org/mailman/listinfo/kde-extra-gear
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic