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.

<  |  >