On Monday 24 March 2008 01:11:32 Sandro Andrade wrote:
> Hi all,
>
> I was wondering about some interesting GSoC proposal
for KDevelop and I
> came up with ideas about metrics and visualization
support. At first
> glance, the aim would be to provide design metrics
mechanisms which
> estimate the quality, complexity, and effort required
by future changes in
> a given development project. The project would involve:
design and
> implementation of a language-independent core for
metric extraction (may be
> by keeping a meta-model of the source-code), selection
of some most
> representative object-oriented metrics (probably
regarding size,
> complexity, coupling, and inheritance), definition of
reference points for
> bad and good (and intermediate) metric values, and
implementation of some
> metric visualization support.
>
> I'm aware that this can be considered a very broad
idea, but I believe that
> providing a extensible and concise metric extraction
and visualization core
> would make future inclusion of new metrics and
visualizations easier.
Hi! To me personally, this whole thing sounds a little too
abstract to imagine
what the exact use of the whole thing within KDevelop would
be. ;)
Given the du-chain we have in kdevelop-4, and everything
parsed completely, it
should however be possible to evaluate such things using
exactly that
information without too much effort. Currently there is only
one
language(C++) that does a complete enough parsing for that,
but we cannot yet
parse a whole project because it takes too much memory. Also
the parsing
isn't "perfect" yet. So if you'd work on such a
thing, you might be missing a
foundation to be actually able to test the stuff.
Also, at least me personally, I'd prefer seeing projects on
KDevelop this year
that work on one of the important missing peaces, or on
fixing up the
foundation, instead of adding "cool" stuff built
on an incomplete/buggy
foundation. KDevelop-4 is currently in a state where it
finally needs to
become "useful". 
Just by the way, me I'm going to apply this year for a C++
support related
project, to fix the "incomplete foundation"
problem mentioned above, at least
for C++.
Here is some ideas what might interesting this year from my
personal POV:
- Python support(Integrate debugger, integrated python
shell, finishing the
python code completion)
- User Interface Improvements: Think about the workflow,
file management,
multi-screen support, etc.
- Project management improvements: Make the cmake support in
kdevelop-4 as
easy as automake support in kdevelop 3(Allow adding targets,
files, etc.
through UI)
- Distribution integration(see
http://techbase.kde.org/index
.php?title=Projects/Summer_of_Code/2008/Ideas#KDevelop)
Just by the way this doesn't mean that your initial Idea
wouldn't work. It
just sounds a little too abstract to imagine how exactly it
would look, how
it could be implemented, whether the needed foundation is
there, and whether
it is feasible to be implemented during SOC.
Greetings, David
_______________________________________________
KDevelop-devel mailing list
KDevelop-devel kdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel
|
