[kgraphviewer-devel] Hi and things to do

[Gaël (aka Kleag)]

Hi,

and hurray to Milian to be the first poster to the list :-)

On Friday 09 April 2010 03:42:52 Milian Wolff wrote:
> Hello everybody!
> 
> Some of you might now me from my contributions to Kate/KDevelop. I recently
> started using KGraphViewer in Massif-Visualizer [1] and started patching it
> so it can cope with my usecase (esp. optimizations to make it work with
> huge call graphs).
> 
> I wonder what you guys are up to? What is still required? Anything you plan
> to implement in future?
On my side, the TODO file lists what I planned, but in fact, I don't work a lot 
on kgraphviewer since some time.

> 
> Here is an unsorted list of things that are still suboptimal in my eyes:
> 
> # KPart Integration
> 
> I created the public interface that can be used by others that use the
> KPart but need more than the default KPart interface gives us. I think we
> should make sure it has everything that we could possibly return, and esp.
> the signals and slots in the KPart itself should be as many as possible.
> My experience with Kate interfaces is: Better more than less. I - as a
> user - hate to cope with different versions of an interface. Yet it's
> still a "solution" if we forget anything.
Yes, it's good to be able to do the maximum of things with the part. But, is 
this solution in the plugin spirit of parts ? Don't you think that most of 
things should be done through signals and slots which avoid to link at compile 
time with the plugin ? Well, the signals/slots solution always semmed 
problematic to me because even if there is a lower coupling, there is also mor 
bugs possibilities...

> 
> Still, I'd like your feedback. Esp. from Sandro, what is required to get
> your ControlflowGraph plugin up and running? Just a stable release? Btw.:
> Any plans to finish the work you put into it? :P
> 
> # Code cleanup
> 
> Don't get me wrong: The code is mostly pretty good. But still there are
> parts where I have the impression that you, Gael, wanted to get something
> working instead of caring about having a "proper" solution. That's not a
> bad thing for a first release, esp. considering how well it works. But
> there are really many parts in the code that could use a cleanup /
> refactoring / optimization.
That's perfectly right. I must confess that I was more interested in obtaining 
a working solution for myself than anything else here and that I just ensured 
that all the required features where working quite well. So, yes, there is 
surely a lot of polishing to do, at least.

> 
> # GraphicsView Cache
> 
> I notice that none of the graphicsview items have a cache property set,
> shouldn't we use at least the ItemCoordinateCache? We should really check
> whether that improves things (I hope so) and use it where possible.
I don't know at all the cache properties of QGraphicsView!

> 
> # Unit Tests
> 
> There are no tests at all. Could we add at least a few?
Yes, we should. I never know where to start with unit tests...

> 
> # Library VS QProcess
> 
> Why can a graph be created by both, Library call and QProcess dot
> execution? 
This is an historic thing. Up to 2009, kgv was only using the QProcess and I 
was suggested at this time (was it Sandro or Tomaz?) to use the library 
instead. In fact, I did not know this library before and when I first 
discovered it I did not like its API a lot. Then I finally tried this solution 
with the idea to verify if it was really better. 

> In my eyes only one should be required and supported. And I'd
> opt for the former since it's probably better performance wise. Gael,
> could you comment on this? 
I completely agree, the QProcess version should probably be dropped. But the 
parsing code should be kept somewhere as it could be useful as a basis to 
handle future formats (even if it should be rewritten to use Spirit V2 instead 
of V1). Well, if we remove it, it would also remove the dependency to 
boost::spirit.

> You also said that I commited some change that
> breaks one but works in the other :-S I still have to fix that...
I was not clear enough: when looking at your changes I discovered the bug, but  
it was surely present before! I still have to look at it...
> 
> # Stable release
> 
> KGraphViewer works, performs ok and has the most required features. What
> about a (first?) stable release? I'd appreciate that since it would mean I
> could release a first version of massif-visualizer.
There were already "stable" releases that you can find in previous extragear 
releases and on kde-apps. But, you're right, as sais others before, a new 
release should be done, and probably in a better way than before.

> 
> # Rest
> 
> That's it for the moment. If I remember other things that should get done,
> I'll write more mails. Oh and I'd appreciate it if you could tell me who
> you are so I have an idea to whom I'm talking :)
So, I'll present myself :-) I'm a 39 years old research scientist in the field 
of natural language processing. I developed kgraphviewer to have an easy ti 
use, pretty and well integrated to the desktop tool to look at the results of 
the linguistic analyzer we developed in my lab (I hope to be able to release 
this analyzer in GPL a day or another!), instead of the Java based things that 
were available at this time.

I'm currently more in a "maintenance mode" for kgraphviewer, work and fomily 
life taking most of my time. So, I'm very happy to see people interested in 
developing new features and new uses for kgraphviewer!

Best regards,

Gaël
-- 
KsirK - a world domination strategy game 
http://techbase.kde.org/Projects/Games/Tactic_and_Strategy/KsirK

KGraphViewer - a GraphViz dot graphs viewer and editor based on a reusable 
part
http://extragear.kde.org/apps/kgraphviewer