Zwabel’s Weblog

November 5, 2008

KDevelop4: Now with refactoring!

Filed under: Uncategorized — zwabel @ 3:48 am

When I started hacking on KDevelop4 one and a half years ago the goal was clear: Use the duchain architecture, together with my previous code-completion programming experience, to build excellent C++ code-completion in KDevelop4. At that point I thought the duchain was a good representation of the C++ code, and only the user-interface part was missing. I didn’t know that it was still far away from that.

So after some time, it showed that all these goals were very ambitious:
1. Code-completion
2. Intelligent code-highlighting
3. Make it efficient, make the editor usable while the parser is working(A hard task in its own)
4. Simple local refactoring
5. Real Project-wide quickopen
6. Project-wide refactoring

The problem is that the duchain is a very detailed and expensive to compute code-representation. Just a year ago, if you would have let KDevelop4 parse the whole KDevplatform project into duchain, you would have had at a memory-usage of about 3 GB, and it would have taken a sheer endless amount of time. During this year’s summer of code project I tried changing that. The basic “theoretical” structure and API have stayed similar, but the whole backend is nearly rewritten in a way that now allows the duchain to at some point become more efficient than what we had in KDevelop3, and much more efficient than anything a java-IDE like Eclipse could ever get. 🙂

Anyway, given the fact that together with KDevelop4’s C++ support, an overwhelmingly big architecture had to be pulled, my plan for KDevelop release 4.0 was at least finishing goal 1, 2, 3, and 4. Due to the computational expense of the duchain, I thought 5 and 6 were just not realistic. Those were ment for KDevelop 4.1 at best.

During the last months or even just weeks, things have changed dramatically. The key was the idea to allow different processing-levels in the duchain. With a very low processing level, KDevelop will not process anything that is within a function-body, which takes away a large part of the complexity. Interested entities can now just tell the duchain that they want the data for specific files at a specific processing level, and the duchain will check whether the data is available, up-to-data, etc., if it’s not lets the background-parser crunch through the data once again using the correct processing level, and notifies the entity of the completely processed data. Since even in the lowest processing level, we always have the both way #include structure available, this enabled KDevelop to do complex use-searching or refactoring, based on a project that was only processed with the lowest processing level. The refactoring component just needs to walk the inclusion-path back to see all files from where the declarations are visible, then requests the duchain to return all those files in the highest processing-level which includes uses, and then perform whatever action is desired on those.

A few days ago I presented you the use-searching component, which was the first part that profitted from that architecture. Today I’ve spent my whole day creating a duchain based project-wide declaration rename functionality. This is a great feeling, because right from the beginning, this has always been the point farthest away. It requires a high level of precision and reliability from the duchain, which it finally actually seems to deliver. Don’t expect it to be perfect yet, since it’s largely untested, but expect it to be there. 🙂 One great thing about this is that this whole thing is language-independent, so it may work with any language that builds a DUChain, although we aren’t planning to ship anything else than C++ in the near future.

So here we go:
The functionality is accessibe through the context-menu, or through any other many that handles a Declaration. Just right-click the name of a Declaration in the editor window, and click “Rename …”.




Now you see a dialog that has two tabs. In the left tab, you see the uses-widget that I’ve presented last time, somewhat polished using ideas from a mockup posted as a comment to my last blog entry. It allows you getting an overview of the actions that will be performed, since it exactly shows the places that will be changed. In the second-tab there’s a html navigation-widget, that allows you seeing and navigating all kinds of informations about the declaration you are just renaming. At the top you see a line-edit, into which you can just write the new name, hit “replace”, and KDevelop gets going.

Currently you should not try this on your most central classes, because the computation may become very slow.

So now the most demanding tasks on C++ support are finally done. In the next time I’m going to try making it faster, fix bugs, and add a few yet missing smal code-completion features. So this area is on target for the 4.0 release.

Since my last blog touched off a lot of discussions about the UI, I’ve got enough of that, so please no comments about that area. Just one thing: We will try find a balance between feature discoverability, feature richness, and simpleness. Be sure that the count of menu-entries will be lower than on the screenshot, the count of default docks will probably be about the same. Now the real problems we still have to fix is project-management, building, debugging, etc. so if anyone wants to help, jump right on board. 🙂

In my next blogs, I will present more C++ features that are available in KDevelop4, and that I could not live without. 🙂



  1. I must tell you that I admire the effort that you are putting in KDevelop4. You are making it actually worth giving it a shot. I hope I can use it soon. So, Is it stable enough to being really used in projects?.

    Comment by Carlos Licea — November 5, 2008 @ 4:51 am

  2. David, I admire your efforts too 🙂
    To Carlos: it’s stable enough for daily projects. Some of us use KDevelop for our C++ works.

    Comment by Evgeniy Ivanov — November 5, 2008 @ 5:38 am

  3. Nice! That kind of refactoring is something I do a lot, and although I’ve now jumped on QtCreator, if KDevelop can pull of refactoring support I’d switch again in a heartbeat. I miss that feature from Eclipse/Java quite a bit.

    Comment by Leo S — November 5, 2008 @ 5:50 am

  4. This is awesome! Like Leo I miss this feature from Eclipse.

    Comment by Ian Monroe — November 5, 2008 @ 6:46 am

  5. I just want to say I love you !!!

    @zwabel I see I can rename a declaration, it will be nice if I can remove and add a method too. Why I need this features? I want to try to duplicate CBuilder functionality. It’s very hard to explain this functionalities, try it and you will see what I’m talking about.

    @Carlos Licea :” So, Is it stable enough to being really used in projects?.” Yes it is, I use KDevelop4 for 2-3 weeks and just works. It’s not perfect, sometimes crush but this problems are fixed very fast.

    Comment by BogDan — November 5, 2008 @ 9:08 am

  6. Wow, this is cool.

    I’m glad Qt Creator came along and encouraged kdevelop develooers to start blogging about this stuff. It’s just awesome 🙂

    Comment by John Tapsell — November 5, 2008 @ 11:01 am

  7. Great stuff! I really hope KDevelop4 will be ready soon… it would be the first time I would switch to an IDE 🙂


    Comment by boom1992 — November 5, 2008 @ 11:49 am

  8. Impressing 🙂

    Comment by Sebastian Sauer — November 5, 2008 @ 1:09 pm

  9. Great. I am a Ruby on Rails developer. I use KDevelop as IDE. I would like to know is there is any improvements for Ruby on Rails support in KDevelop 4.

    Comment by tinku — November 5, 2008 @ 6:55 pm

  10. Any chance of having this as a console tool? (I would like to integrate something like this into Vim)

    Comment by Ivan Čukić — November 5, 2008 @ 7:16 pm

  11. @BogDan: Who knows what features will appear. I have a lot of ideas, but the more important part is making what we have rock-solid now. 🙂

    @tinku: Initially there were be no ruby support for KDevelop4. There seem to be some people interested in implementing it, but that’s stalling I think.

    @Ivan Cukic: Not planned by us, but it is possible. We already have several duchain based command-line apps, most noticably of course the tests, but also a kross wrapper-generator which we use to generate wrappers of kdevplatform classes. So if someone comes along and wants to implement something like this, it would be possible.

    Comment by zwabel — November 6, 2008 @ 12:47 am

  12. Hi, what do you mean when you say “much more efficient than anything a java-IDE like Eclipse could ever get”? Can you elaborate a bit on that?

    Comment by Guillaume Pothier — November 6, 2008 @ 2:35 am

  13. @Guillaume Pothier: I think I’ll write another blog entry about the storage engine, and what makes it efficient.

    Comment by zwabel — November 6, 2008 @ 8:37 am

  14. Thanks for the answer. Huh, another thing on my hope-to-be-in-the-near-future-TODO list 🙂

    Comment by Ivan Čukić — November 6, 2008 @ 3:50 pm

  15. When will KDevelop be released? Do you have any plans on that?

    Comment by Bogdan Bivolaru — November 8, 2008 @ 3:37 pm

  16. What’s the big deal? Any off the shelf Java IDE has been doing way more than this for years.

    Comment by mich — November 8, 2008 @ 5:24 pm

  17. a) C++ is not java, in java it’s much easier to do.
    b) KDevelop did not have it, and most other C++ IDE’s don’t have it. That’s the deal.

    Comment by David Nolden — November 9, 2008 @ 4:56 pm

  18. I’d very much like to try this out…
    Does anybody know a set of svn-revisions that compiles and works (at least as much that one can try it).
    I’d like revisions numbers of kdelibs/kdedevplatform/kdevelop.

    thx so far

    Comment by KiloAlphaIndia — November 17, 2008 @ 10:37 am

  19. …. maybe it would be valuable to put the user revisions into any such presentation…

    Comment by KiloAlphaIndia — November 17, 2008 @ 11:53 am

  20. @KiloAphaIndia: I’m not aware of any serious regressions in the current version, rather there have been a lot of improvements.

    So the most current revision from SVN should be fine.

    Comment by David Nolden — November 17, 2008 @ 2:37 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: