[dot] KDevelop Authors Talk About Their Coming Releases

[Dot Stories]

URL: http://dot.kde.org/1154654739/

From: Jonathan Riddell <>
Dept: aye-dee-ee
Date: Thursday 03/Aug/2006, @18:25

KDevelop Authors Talk About Their Coming Releases
=================================================

   KDevelop [http://www.kdevelop.org] is the premier Free integrated
development environment.  The project is currently working towards
KDevelop 3.4 with a bunch of new features and a major new version
KDevelop 4.  To find out what's coming up in one of KDE's most important
projects KDE Dot News spoke to three of the authors about their current
work and future plans.
    Matt Rogers  Adam Treat  Alexander Dymo
     Please introduce yourself and your role in KDevelop.

     Matt: Hi, I'm Matt Rogers and I'm KDevelop's lead maintainer.

     Adam: Hi, I'm Adam Treat and I hack on many parts of KDevelop. For
the 3.x series, I've worked on the C++ language part, code completion,
split view of header/source and various parts of the shell and library.
For KDevelop 4, I've been hacking on the C++/Java language parts, the
background parser, the codemodel, the documentview, the codeview, the
shell, refactoring the lib into kdevplatform and various parts of the
GUI.

     Alex: My name is Alexander Dymo. I've been a KDevelop developer
since 2002 and maintainer and release coordinator of KDevelop 3.x series
starting from 3.1. I have worked on many parts of KDevelop and authored
the documentation plugin. Also I initially added the "Platform" word to
KDevelop which makes it possible to have KDevAssistant and Kuanta
running on the same codebase as KDevelop.

     Currently I'm helping Matt in maintainership and working on
KDevelop 4 user interface. Also I'm sponsored to work on new Ruby
language support.

     What's going to be new in KDevelop 3.4 and when will it be
released?

     Matt: There's going to be some support for Qt 4 based projects, as
well as some nice improvements to the C++ code completion system. The
code completion is faster, less crashy, and supports more language
features. We don't know exactly when the release is going to be yet,
since we'd like for it to stabilise a bit more and allow time for the
translators to translate things.

     Adam: I'm concentrating pretty heavily on KDevelop 4 right now, but
I know that Andreas Pakulat, Vladimir Prus, Alexander Dymo, Dave Nolden
and others have put quite a bit of work into various bits such as Qt
4/KDE 4 development support, the debugger, code completion, UI
improvements and an assortment of bug fixes.

     Alex: Like Matt and Adam said, KDevelop 3.4 is going to be an
improvement in almost all areas.

     Why is there a need for KDevelop 4?

     Matt: There is a need because KDevelop 3.x won't run on KDE 4. :)
KDevelop 4 is really the next evolution in KDevelop's lifecycle. The
KDevelop 3.x codebase has served us well for a long time, and now it's
time to build on what we've learnt from the KDevelop 3.x series and
build on top of it.

     Adam: As Matt says, we need to convert the code to the Qt 4/KDE 4
platform. That is number one. However, I feel that this provides a
tremendous opportunity to really improve KDevelop by an order of
magnitude or more. KDevelop 3.x was itself a very big leap from the 2.x
series, but it is beginning to show its age with a pile of features and
plugins whose quality varies quite a bit. The result is a very powerful
IDE, but one which has grown into a kind of messy soup of features that
do not always integrate well with each other.

     For KDevelop 4, I want to make the IDE work very well within its
core competency: KDE/Qt development. This requires, amongst other
things, robust and solid language parts to enable consistent and
workable code completion. This is where Roberto Raggi's new C++ parser,
the basis behind the Qt 3 --> Qt 4 porting tool, will serve us well.
Jakob Petsovitz has been very busy creating new parsers for Java and C#
based on Raggi's kdevelop-pg tool, which was itself created from the
template provided by the aforementioned C++ parser. Alexander Dymo is
also slated to use kdevelop-pg to create a Ruby parser. Together, this
should give KDevelop 4 a powerful set of language parts. I can't wait to
see the Java language part in action with Trolltech's new Qt Java
bindings.

     Alex: We just have to hack on something cool, right ;) KDevelop4 is
an excellent opportunity to break things and build them again. :)

     What is the current state of KDevelop 4?

     Matt: It's pretty raw right now. There are some basic things that
work. You can open a file, make some edits, use the KDE 4 Konsole, and
some other stuff, but it's not really very useful for normal development
at the moment.

     Adam: It compiles, it links, and it works for some definition of
'works'. It is very alpha, but you can already get a sense that a lot of
change is involved. The new documentview and codeview parts are in a
preliminary state. The new configuration framework and associated KCM
dialogues are in place. Given some more improvements and Matt finally
wrestling the CMakeLib into place it will really begin to take shape.

     Alex: It's like in the state when I first joined the team. That was
the 3.0 alpha 2 time when the main feature of KDevelop was the ability
to crash :) Of course I'm not serious, but I like that feeling of the
application in its infancy.

     Are a lot of the internals of KDevelop 3 going to be changed for
KDevelop 4?

     Matt: Yes. I wouldn't call what we're doing to the internals of
KDevelop 4 a rewrite, since we're not just wiping the slate clean and
starting over, but we're making some really deep changes in the KDevelop
architecture so that it becomes more useful for other developers who are
looking to develop an IDE like application and want something to build
off. We're also going through and doing a lot of code cleanups,
consolidation, etc.

     Adam: In a word, yes. The KDevelop platform library is undergoing a
huge refactoring and API cleanup. New classes have been introduced to
make integration of the C++/Java/C# language parts easier. Right now, I
am working on merging the library and the shell and reworking the API.
The new configuration framework and project file(s) have also introduced
a big change.

     Alex: Yes, quite a lot but the idea behind our architecture remains
the same. I think that KDevelop changed more radically between version 2
and version 3.
   KDevelop 4 with Qt Designer Integration
     What cool new features do you have currently working?

     Matt: CMake support is partially working, although I can't hit the
magic shortcut and have things build yet. The new codeview is nice.
Adam's done a really good job with abstracting that in such a way so
that'll work with more than one language very easily.

     Adam: The new configuration framework allows every setting that
KDevelop offers to be set on a per project basis. We've also created a
dichotomy between the global project file and the local project file.
The global project file will not contain machine specific paths or other
local configuration settings. Instead, the local settings are saved to a
file in a hidden directory. Finally project managers will be able to
commit the project file to their source control repository which
multiple developers can then share.

     The codeview part is also working although it is buggy. It is
language agnostic and relies upon the language parts to publish a
codemodel and delegate that the codeview part happily displays. It makes
use of Qt's QSortFilterProxyModel and the Interview framework to provide
filters of both the individual translation unit's codemodel and the
aggregated codemodel. For instance, you can now filter the codeview part
to view only the contents of the currently focused document or the
aggregated whole of the project's translation units.

     Probably the coolest feature so far is Matt's seemless Qt 4
designer integration. It really blows what we had in KDevelop 3.x out of
the water.

     What new features do you plan to include?

     Matt: the sky's the limit here really. One of our developers is
working on a teamwork mode as a Summer of Code project. There's a lot of
work that's gone in to that. I have really high hopes that it'll be a
feature that gets used and helps make developers more productive. I'll
also start looking (eventually) at some of the workflow issues in the
KDevelop 3.x series (at least for me) that keeps me from being
productive as I could be and trying to eliminate them. Those issues
mainly involve not being able to do a few things in the IDE itself and
having to go out to a terminal to do what I want. I could rattle off a
few more, but then there would be nothing left for anybody else to
answer. :)

     Adam: Hmm, soooo much... But the major feature, I hope, is that
KDevelop 4 will concentrate very heavily on getting the crucial things
right. We need to concentrate on making KDevelop 4 work well with at
least four languages: C++, Java, C# and Ruby. We need to concentrate on
making sure stuff like code completion and refactoring are robust rather
than providing every app template imaginable. Beyond that, I hope
KDevelop 4 will feature major new refactoring support. The language
parts should really rock... The seemless Qt4 designer integration... I'd
really like to see the UI simplified to take after XCode and Qt 4
designer... The perspectives feature we have planned should blow you
away...

     My personal goal is to make KDevelop 4 so good that core KDE
developers like Zack Rusin (Emacs guy) and Aaron Seigo (Vim guy) just
have to switch. Zack and Aaron will tell you that this is not an easy
goal to accomplish. I'll be very happy if KDevelop 4 becomes the release
known for converting the KDE core developers into KDevelop users.

     Alex: There's no limit of features but this time we'll have to do
our job better and not cram every single little feature in our source.
My own plans include new UI with perspectives and new Ruby language
support with quite a lot of cool features for Rails development.

     Tell us about the meeting you had last year.

     Matt: It was the birth of KDevelop 4. I wasn't there, so I can't
say much else.

     Adam: Didn't attend. Sorry.

     Alex: Some time in the past (IIRC that was during Akademy 2004 in
Ludwigsburg) I promised that we (KDevelop Team) would meet in Ukraine. I
kept my promise and we (me, Roberto Raggi, Harald Fernengel, Ian Geiser,
Richard Dale and Jens Herden of Quanta fame) actually met and had a
one-day conference and a hacking session in Kiev. The conference itself
did not attract much attention from local public but during the hacking
session we had a lot of fun, tequilla and vodka and of course produced a
lot of code. Roberto Raggi was hacking like mad and implemented the
parser generator we now use to build language parsers. Harald Fernengel
was busy porting KDevelop3 to Qt4 and integrating MVC pattern into
KDevelop source code. Ian Geiser and myself were working on new approach
to Qt3 qmake support, Richard Dale started his work on new Ruby parser.

     It was decided in Ludwigsburg to join the efforts of KDevelop and
Quanta teams and use the common source base. Therefore we also invited
Quanta developers to come. Unfortunately Andras Mantia could not make it
but Jens Herden actually did and his presence and patient reminders
actually made us think about the needs of Quanta.

     What is it like developing for the moving platform that is KDE 4?

     Matt: It's not too hard now that the kdelibs4_snapshot has gone
away. That was perhaps the biggest thing. We want to move quickly to the
newer technologies since we've been the ones requesting them a lot of
the time so not having to worry about the snapshot is better for us.

     Adam: Quite enjoyable actually. It was rough towards the very
beginning, but things have stabilised somewhat now. I'm quite thrilled
developing with Qt 4 and all of the improvements to the underlying
libraries.

     What is the collaborative mode you have planned?

     Matt: The teamwork mode, as it's called, will allow developers to
review a set of patches in real time. Collaborative editing on one or
more files is also planned, but I don't know when that will be done.
Currently, patch review is commonly done on a mailing list, and while
this method works, it can take a long time to get all the changes a
patch makes discussed, reviewed, approved, etc. The teamwork mode will
allow a group of developers to do a patch review in near real-time,
making that process much faster than it currently is.

     What improvements or changes are being made to buildsystem support?

     Matt: There is going to be a tonne of stuff. Autotools and CMake
will be supported in the beginning, and the goal is to allow the
developer to do everything from within the IDE. Ease of use is key here.
With KDevelop 3.x, if you want to add a check for a package using the
Autotools, you've got to edit the configure.in.in file, know all the
syntax, etc. With KDevelop 4, my goal is to allow the user to right
click on the project, choose 'Add an external dependency' and basically
create the config check from a nice dialogue rather than having to edit
files.

     Adam: The project manager part is going to provide a GUI
abstraction of the underlying buildsystem. At least, that is the plan.
You will no longer see a visual difference between using the Automake,
QMake, and CMake build systems.

     I'd also like to take this opportunity to ask for some help. We are
looking for a good Windows hacker to help us provide general testing of
the KDevelop 4 build on Windows and perhaps an MSBuild target.
Similarly, if we could find one or more Apple hackers who want to see
KDevelop 4 work well on the Mac, it would be a real plus. If you are
interested in helping, please get in contact with us via the
kdevelop-devel list or on freenode: channel #kdevelop.

     What new languages are being added?

     Matt: Adam Treat and Jakob Petsovits are working on Java and C#
support.

     Adam: Currently C++, Java and C#, but Alexander and Richard are
slated to give us a kickass Ruby language part too AFAIK. The Java and
C# parts are not producing a codemodel at this time, but Jakob, Hamish
and I are working on it.

     Alex: kdevelop-pg parser generator that Roberto Raggi wrote allows
us to push our language support to their limits. With kdevelop-pg we
have AST creation with the parser for free, AST walker class for free.
Today thanks to Jakob Petsovits we also have backtracking and error
recovery for our parsers. That all enables us to implement better
language parsers and integrate them into KDevelop faster than we could
have done before.

     What is the new ideal library?

     Matt: That's Alexander's area, although I will take a moment and
plug the Eclipse-like perspectives we're going to be adding to KDevelop
4.

     Alex: Starting from KDevelop 3 alpha4 it was decided to use the
KMDI library to serve its GUI needs. And that was our worst decision in
my mind. KMDI enabled us to have four UI modes so KDevelop could look
like Borland Delphi, MS Visual Studion and IntelliJ IDEA at the same
time. But KMDI also threw us back to the stone age of programming mostly
because of high complexity and low maintainability of the library code.
In reality the majority of our users were picking up either toplevel
(Delphi-alike) or ideal (IntelliJ IDEA-alike) mode. Therefore I started
to work on new UI library implementation which was called Ideal. The
design goals were simplicity, code readability and maintainability. Some
parts of the new library were ready for KDevelop 3.3 and KDevelop 3.3
users could enjoy additional "Simplified Ideal" mode. The improved
version of the mode is now the default for KDevelop3.4. I continued the
work for KDevelop 4 and now it's under heavy development. New version
has new features under the hood.

     Already working is the support for areas (read Eclipse-like
perspectives). And also most cool features from former toplevel mode are
being integrated into the library so that our multihead users are going
to be happy with KDevelop 4 too.