As far as kicker code is concerned, I think, a code comprehension tool can be easily used for this purpose.<br>
In kdevelop, you can import kicker and see all its inheritance diagram.<br>
In source-navigator, you can have much better view of all crossreference,inheritance heirarchy plus many other things.<br>
<br>
I think, codes must be documented, but kicker is not a mess.<br><br><div><span class="gmail_quote">On 03/10/05, <b class="gmail_sendername">Wade Olson</b> <<a href="mailto:wadejolson@gmail.com">wadejolson@gmail.com</a>
> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">True, which is why UML is considered one of many artifacts in software<br>
development.<br><br>If you're an architect and the only thing you transfer to your<br>programmers: UML, or if you're a programmer and your designer only<br>gives you UML, something's grossly wrong. The name alone tells you
<br>what it is, otherwise it'd be UDL: Unified Description Language.<br><br>Like XML or similar, old-schoolers condemn it, marketers promote it as<br>a holy grail, and the pragmatic see it as just another tool and apply<br>
it where userful.<br><br><br>On 10/3/05, Aaron J. Seigo <<a href="mailto:aseigo@kde.org">aseigo@kde.org</a>> wrote:<br>> On Monday 03 October 2005 08:24, Wade Olson wrote:<br>> > To me, UML diagrams allow for both better introductions to new
<br>> > participants, as well as helps more experienced people to refine the<br>> > code.<br>><br>> high level code documentation is excellent for helping people do design<br>> recovery (which happens when learning a new code base as well as hunting for
<br>> design issues 6 months after having written something yourself ;). i would<br>> welcome an ongoing documentation of plasma as it takes shape.<br>><br>> on the flip side, i find uml nearly useless for describing new design concepts
<br>> as it says everything about structure to me and almost nothing about the<br>> why's and wherefore's implied by the design. which is to say: what the person<br>> creating that design was thinking at the time.
<br>><br>> --<br>> Aaron J. Seigo<br>> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43<br>><br>> Full time KDE developer sponsored by Trolltech (<a href="http://www.trolltech.com">http://www.trolltech.com
</a>)<br>><br>><br>><br>_______________________________________________<br>Panel-devel mailing list<br><a href="mailto:Panel-devel@kde.org">Panel-devel@kde.org</a><br><a href="https://mail.kde.org/mailman/listinfo/panel-devel">
https://mail.kde.org/mailman/listinfo/panel-devel</a><br></blockquote></div><br>