<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 4, 2013 at 6:36 PM, Aurélien Gâteau <span dir="ltr"><<a href="mailto:agateau@kde.org" target="_blank">agateau@kde.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I worked on generating diagrams for KF5 frameworks. The current output can be<br>
browsed here:<br>
<br>
  <a href="http://agateau.com/tmp/kf5" target="_blank">http://agateau.com/tmp/kf5</a><br>
<br>
Those diagrams are created from cmake graphviz output of individual<br>
frameworks, which is then processed and aggregated with scripts available from<br>
<br>
<a href="http://quickgit.kde.org/?p=scratch%2Fgateau%2Fkf5dot.git" target="_blank">http://quickgit.kde.org/?p=scratch%2Fgateau%2Fkf5dot.git</a><br>
<br>
My initial goal was to create one big diagram, but it is currently way too<br>
messy, so I also generated one diagram per framework. For tier1 and tier2<br>
frameworks I included the Qt libs, but removed them for tier3 and tier4 to<br>
reduce clutter. I think those individual diagrams would be a nice addition to<br>
the Doxygen doc of each framework.<br>
<br>
I initially used tred from graphviz to reduce clutter, but moved away from it<br>
because it was a bit too happy to remove dependencies: for example after<br>
running through tred, KCMUtils appeared to have only one dependency: XmlGui.<br>
<br>
I am considering generating simpler diagrams by hiding the framework targets.<br>
Hopefully it will make the big diagram more readable.<br>
<br>
Aurélien<br>
_______________________________________________<br>
Kde-frameworks-devel mailing list<br>
<a href="mailto:Kde-frameworks-devel@kde.org">Kde-frameworks-devel@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/kde-frameworks-devel" target="_blank">https://mail.kde.org/mailman/listinfo/kde-frameworks-devel</a><br>
</blockquote></div><br></div><div class="gmail_extra">Hi Aurélien!</div><div class="gmail_extra">This is a very nice effort, I already gave it a try and ended up quite frustrated. Good work!</div><div class="gmail_extra">

<br></div><div class="gmail_extra">Maybe it would be interesting if we could have also a module dependencies diagrams, without the specific libraries inside, that sound like an implementation detail in some cases. For example, looking at KBookmarks, having an arrow specifying that KService depends on KConfigCore is a bit too much?</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Aleix</div></div>