the written word remains

I'd love to learn how you use KDevelop, what you use, what is your workflow, etc. If you're here at Akademy and up for a quick user testing session, grab me at any time (currently I'm at Demola). If you don't know how I look like, ping me at irc (nick: adymo, #akademy and #kdevelop channels).

We rescheduled KDevelop BoF from Friday to Wednesday so that more people can attend (and so that we ourselves can attend :)).

KDevelop BoF will happen on Wednesday July, 7th at 16:00 in Area 4. The BoF will be held by yours trully, Aleix and Milian.

Here's a list of potential topics for the BoF

• usage patterns
  • kdevelop as improved kate
  • kdevelop as 1-project ide
  • kdevelop as an ultimate work tool - many projects, sessions, etc.
  • which usage patterns are best supported right now and why
• what are sessions: intended use, scope, limitations
• projects
  • idea behind multiple projects
  • multiple projects and buildiing
  • multiple projects and other plugins
• what happens behind the hood in UI
  • what are areas: intended use, limitations
  • what are workingsets: intended use, limitations
  • concept of views, saving/closing views, views and areas
• what happens behind the hood in c++ support
  • how includes are found
    • when automatic resolver is used
    • which buildsystems and when can do
  • how and when completion, assistant hints, refactoring etc. work
  • what is duchain and what it does
  • how to tune performance
• how to create and use snippets
• how to customize the IDE
  • customizing editor (modelines, kateconfig)
  • creating a custom shortcut scheme
  • kdeveloprc - what's there, what to change
  • quick overview of the extension architecture
  • writing language support plugins: very brief intro
• best workflows
  • quickopen instead of class view
  • navigation explained
    • what is context, what context navigation do
    • all other navigation features
    • tab/notab view management
• Q/A

Come by, we'll be glad to talk to you. It's the only chance to tell us everything what you think about us and we promise to listen quietly and attentively ;) And of course we promise to finish this long before the semi-finals football match starts :)

It's been more than a week since I got back from Kate and KDevelop Hacksprint we had in Berlin, but I feel it's never late to write a blogpost about it.

The hacksprint was full of hacking, drinking awesome German beers, socializing, sightseeing and many more. I have to say I enjoyed every minute of it. Many thanks for Milian for organizing this event!

This time I set up a bold goal for myself. I had to make KDevelop 4 good for my everyday work and finally stop using KDevelop 3. For that to happen I had to do three simple things:
1) don't let C++ parser to take all my memory when opening Ruby interpreter sources
2) have proper X session management support to correctly reopen all my running KDevelop sessions at X startup
3) implement Ruby language support (at least) with the same feature set as in KDevelop 3

Thanks to a good beer and to a good company, I did everything I planned!

Ruby Support

Ruby support features we have so far in KDevelop 4 are:

• Ruby application template
• Ability to open existing projects with Generic Project Manager


• Quick Open Files/Classes/Functions and a Class View
• Outline and Previous/Next Function navigation


• Rails-specific switching between controllers/models/views/tests


• Run Current File feature with automatically created launch configuration
• Run Current Test Function (works only for Test::Unit framework), again with automatically created launch configuration

I've imported Gitorious project (yeah, it's Ruby on Rails!) to illustrate my words.

Quick Open Function:



Rails-specific "Switch to View" navigation using regular Quick Open widget:



Run Current File:



See more screenshots at the Ruby support wiki page.

To try Ruby support yourself, you'll need to compile the plugin from playground yourself. I have no plans to release it yet, but if you'd like to test it or use it for everyday work, please do. I'm writing Ruby code with KDevelop4 every day now, so the Ruby support is stable and I intend to keep it that way in the future.

This is only the beginning. Ahead is the long way to a best possible Ruby support in KDevelop 4. Stay tuned!

The more I see things like iPad, iPhone, iTunes, etc. coming, the more I am motivated to continue using, developing and promoting Free Software. This world needs people who care about freedom in general and digital freedom in particular. And we are those people.

Two important things made me busy lately. One is the preparation of the annual KDevelop Team Meeting which I'll write about later and another one is preparing for my RailsConf 2009 presentation called "Advanced Performance Optimization of Rails Applications".

I've been working professionally with Ruby and Rails for 3 years and always found it funny when my applications turned out to be slow. And when I say slow, I don't mean anything like I complained about in my previous posts on KDE performance.

The performance of normal Rails application is measured in seconds :) The performance of slow Rails application - in dozens of seconds. You simply can't write a KDE/C++ application that would be that slow.

But that doesn't mean your Rails application is doomed to be slow. Contrary to that, it can be snappy and feel more like a desktop application rather than like a slow web site. But you do need to know how to do that.

So, after all those years of fighting for performance I decided to tell the world on how to make Rails applications fast. If you're interested in the topic, please see my presentation abstract and other blog post for details.

Someday I believe we'll be optimizing Ruby applications in the KDE world as well ;) QtRuby and Korundum are the great frameworks. They have C++ code behind them so performance will never be as much of a problem as it is with Rails. And they make developers extremely productive. Once just out of curiosity I rewrote my Sublime UI library from KDevelop in Ruby and spent 3 days for that. C++ version took me 3 months (excluding the time I didn't work on it) and it's not even finished yet!

KDE as a project was always keen on using the best tools for the job. I hope one day we'll seriously pick up dynamic languages. I dare to imagine how that will boost the already robust and speedy KDE development ;)