the written word remains

"Scripts" menu has been a dark horse of KDevelop since it first appeared. Almost nobody knew what it was and understood what hides beneath it (myself included until recently). But in fact the menu is the only visible hint KDevelop3 has some scripting features.

Those features are not so powerful as in Emacs, but they solve different problem. Emacs has Emacs Lisp to:

• extend the environment
• and automate common tasks.

All modern IDE's I know about use different approach. They have:

• extension system with plugins written usually in the same language IDE was created
• and scripting language or scenarios to automate tasks within the IDE.

You can write plugins in C++ for KDevelop and or course you can write scripts. KDevelop exposes its internals via DCOP therefore the choice of scripting language is virtually unlimited. Either your language has DCOP bindings (like Perl, Java, Python, Ruby, KJS) or it can execute dcop command via shell.

Imagine a C++ project with some parts written in Python or Ruby. You naturally want it to be opened as C++ project to have nice integration but you also want a way to easily run your Ruby and Python programs. When working on Ruby projects, you are able to run currently edited programs. But there's no such option when a C++ project is opened. So why don't we implement that with a script?

KDevelop automatically loads all scripts it can find into the "Scripts" menu. The search path by default is $KDEDIR/share/apps/kdevelop/scripts, $KDEDIR/share/apps/kate/scripts and their user-editable equivalents ~/.kde/share/apps/kdevelop/scripts and~/.kde/share/apps/kate/scripts.

Script has to be an executable file and needs to have a .desktop file with a short description. Our script menu item will be called "Run Ruby Program" and the actual script will be a shell script called runrubyprogram.sh. Below are the sources for runrubyprogram.desktop and runrubyprogram.sh I wrote today:

runrubyprogram.desktop

[Desktop Entry]
Encoding=UTF-8
Name=Run Ruby Program
Type=ShellScript/bash
X-KDE-ScriptName=runrubyprogram.sh

runrubyprogram.sh

#!/bin/bash

#get the name of active file and project
file=`dcop $1 SimpleMainWindow caption`
projectdir=`dcop $1 KDevProject projectDirectory`

#strip "KDevelop" from the window caption to get the real filename
file=`echo $file | sed 's/ - KDevelop//' | sed 's/file:\/\///'`

cwd=`pwd`

if [ ! -z $projectdir ]; then
    #strip projectname
    file=`echo $file | sed 's/^[^-]*- //'`
    cwd=$projectdir
fi

#run current file with ruby in KDevelop
dcop $1 KDevAppFrontend startAppCommand "$cwd" "ruby $file" "false"

As you can see, two DCOP calls are made to get the name of currently opened file and project directory and one DCOP call to execute a command inside KDevelop. Each DCOP call is a call to some part of KDevelop which exposes methods via interfaces. For example, startAppCommand is a method of KDevAppFrontend interface. There's no documentation about what is exposed, but just run kdcop tool to explore the complete list of interfaces and their methods and check how they work.

When you save your script in ~/.kde/share/apps/kdevelop/scripts and restart KDevelop, you'll be able to run your ruby programs having a C++ project opened like shown in the screenshot below.


PS: this post was inspired when I was reviewing the KDevelop wishlist named "Unable to execute Python scripts in a C/C++ project".

PPS: I do believe we can make scripting more powerful and easier with KDevelop4 and we have two great technologies - QtScript and Kross for that... but this is another story ;)

I know I promised to blog often about KDevelop4 progress, but I did not intend to write one more post today ;) The reason I'm doing this is that someone came today to #kdevelop IRC channel and asked whether we can open more than one embedded Konsole toolview in KDevelop. Of course my answer was "no sorry" because in KDevelop3 the usual modus operandi is 1 plugin => 1 view.

But this is not the case in KDevelop4 anymore. During architecture rework that was done by yours trully and Andreas Pakulat we introduced so-called "toolview factories". So each KDevelop4 plugin now registers a toolview factory and then the shell application uses the factory to add toolviews when necessary.

Until today, factories were used by mainwindow only once and only one toolview was visible on the screenshots from my previous post. Today I though that nothing prevents me from implementing a nice dialog to add new toolviews. After several minutes of hacking (actual view creation is only 2 lines of code thanks to Sublime library, everything else I committed was the UI for the feature) I got this:




As you can see, there's no restriction anymore to the number of toolviews. You want 10 konsole's - you'll get them! Also Qt4 dockwidget management system allows to group dockwidgets in tabs so some toolviews can be nicely kept together.

Ok, that's all for today. Next time I'll leave UI and tell you about project management in KDevelop4. Stay tuned...

It's been a long time since I last talked about the progress on KDevelop4. This has to change ;) I'll try to keep everyone informed about recent developments in KDevelop4.

Last time our new user interface concept ("Sublime") was covered in commit-digest article. At that time only the sublime user interface library code was available. Today we have two major UI design decisions implemented.

First was the support for areas (the KDevelop's name for perspectives). Area in KDevelop is the set of views (documents) and toolviews (docks). At this moment KDevelop has only "coding" area, debugger and design areas will be used once respective plugins are ported to KDevelop4.

Second major design decision was multi-mainwindow operation. KDevelop3 with its only one mainwindow and non-detacheable toolviews was hardly optimal for dual monitor setups. KDevelop4 allows to have as many mainwindows as necessary.

The interesting thing is how multiple mainwindows and areas work together. Of course, different mainwindows can have different areas. Basically opening one more window with "debug" area will be the default way to do debugging. Same for Qt UI design - you will have new mainwindow with "design" area to work on Qt .ui files.

But that's not all we can do. Eclipse pretends it can show one perspective in two or more mainwindows. KDevelop4 now does that as well, except that it doesn't pretend the area is the same in all those mainwindows. You can duplicate mainwindow with "coding" area but what you get is cloned area called "coding (copy)" shown in the new mainwindow. This means all view/toolview layout and settings belong to the new cloned area so no confusion happens when you close your windows and save areas.

In the screenshot below, you can see one KDevelop program with three mainwindows. The background window shows "coding" area, two topmost windows show the clones of "coding" area with different view/toolview layout. So nothing will prevent from using KDevelop in dual-monitor setups anymore. "New Window" action from the window menu will duplicate the mainwindow and clone its area as necessary. The cloning operation is relatively cheap, resources are used just to create a new mainwindow and views inside it. No KDevelop plugin is loaded for the second time.

Toolviews that use plain Qt4 dockwidgets with no hacks are handy as well. Unlike KDevelop3, you can dock/undock and close them completely.

Splitting is of course in place too, but with slightly different logic than in KDevelop3. Now it behaves more like Kate when current view under the cursor is splitted rather than the whole region with views.

Don't bother looking at combobox that we currently have as a way to switch between views because it's our temporary replacement for a tabwidget. Everybody knows that tabwidget doesn't scale when lots of files are opened and everybody hates QTabWidget for extra bevel and border. We hated tabwidget too so we had to avoid it ;)

All that is implemented in KDevelop4 shell in <200 lines of code ;) Ok, ok, another 3k loc reside in Sublime library :) Sublime is the fourth UI library KDevelop uses and the third one I wrote. And I do hope it will be the last one. This time I believe I got it right. At least the code is surely better than infamous KMDI library and Sublime certainly is more capable than my previous NewD aka SimpleIdeal and Ideal libraries. Also this time the I wrote an extensive test suite to guarantee that UI is stable and bug-free.

So, enjoy the screenshot and don't just wait for KDevelop4. It is high time to do an IDE right and we know how to do that this time. What we need is you :) Join us to create the IDE of your dream!