the written word remains

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!

IDE's are usually created to make things easier and faster for developers. And most of them achieve this goal to some extent. But there is one group of people that has always suffered from IDE's. Those people are application template developers.

Tons of subtle application template formats were invented to bend to submission those miserable souls who wanted to add their little template!

Anjuta requires you to write a nice xml file with template description including wizard page layout options, list of template files, directories and of rename rules. To do substitutions in the template files you have to spend a week learning extremely powerful but also extremely complicated autogen format so you could write something like this or this.

Eclipse makes the process even more interesting. There's no application wizard, there's no template format. When you want something like that, you just have to code it in Java by yourself. Easy, isn't it? Choose between org.eclipse.cdt.ui.wizards.NewCProjectWizard, org.eclipse.ui.wizards.newresource.BasicNewResourceWizard or org.eclipse.ui.INewWizard, subclass/implement, write everything else by hand and get something like I got for KDE-Eclipse

KDevelop3 was not really different. Our first template format required you to write a template description and a perl script with installation instructions. Our second template format combined descriptions with processing/installation instructions to the single file. To make things even more interesting, we did not allow to have subdirectories in the templates, so you had to write special subdirectory creation and file copy instructions when you wanted for example to put the main.cpp into /src.

I created several application templates for KDevelop by myself and found that process too complicated and annoying. So when I was working on KDE-Eclipse I thought of ideal template format and soon figured out that a simple tarball is the format of my dream.

Really, why don't application wizard just extract the tarball and so some variable substitutions? I implemented exactly that: extraction + substitution and that worked better than any of those sophisticated template systems I know about.

So when the time had come to implement the application wizard for KDevelop4 I didn't hesitate and did the same thing again. So from now to create an application template for KDevelop4 you just need to:

• have a directory with your project
• place variables in file names and contents
• write very simple .kdevtemplate file with a description like this one
• and pack it

As an example, take a look at our Qt4 application template in the unpacked form.

Of course, the variables that are not known to the application wizard has still to be declared in .kdevtemplate so that user can be asked at project creation time. But the whole thing is still as simple as possible and I will make sure we will stick to KISS principle and won't harry apptemplate developers anymore ;)

IDE's project management features are what everyone can see. Together with advanced language support features, proper build system support is the most prominent feature that differentiates IDE's from various editors, advanced and not.

And proper project management with proper buildsystem support is hard. KDevelop3 was very good at that. Anjuta only recently got close to what our Automake manager had for 4 years. My KDE-Eclipse autotools plugin did get some attention by RedHat guys after I stopped working on it, but I don't know what happened next. Seems like "fedora eclipse" project now superseded it. So even Eclipse doesn't have something on a par yet.

This all means KDevelop's features are still unique. Especially unique is QMake manager which has no alternatives I know about. After Andreas Pakulat took my qmake parser and vastly improved the manager in KDevelop 3.4, we can open and manage the most complex qmake project - the whole Qt library (both 3.x and 4.x versions).

But the time doesn't stop and KDevelop development doesn't stop either. We always wanted to change two things in 3.x - make it possible to open more than one project at a time and avoid code and UI duplication between buildsystem plugins.

As for today, in KDevelop4 we managed to realize our plan. First, Andreas Pakulat implemented support for opening several projects at a time. Second, we used Roberto Raggi's project management architecture with one user-visible "Project Management View" which displays information from various build system managers. That all grants the popular wish to open many projects and solves code maintainability and complexity issues at the same time!

You can see the current state of things in the screenshot below where I've opened two QMake projects using QMake Manager and KDevelop4 project using Generic Manager (CMake Manager is not yet ready). Looks cool, doesn't it? ;)

"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!

A lot of water flew away since I promised to blog about RailsConf Europe 2006. And one major event started and finished also during that time - the aKademy conference. So during one September I managed to attend two software conferences which I haven't covered in my blog yet.

So here comes by aKademy report.

Everybody who blogs about aKademy agrees that aKademy was a great event and everybody thanks to Marcus and the guys in blue. All I can do is just add my personal thanks to all aKademy team who did a great job and were really supportive when I was bugging with my usual give-me-my-visa-paper requests!

As usual at aKademies, I didn't code much but rather spent a lot of time communicating with people. What's important is that this time we (as in KDevelop team) managed to solve (or at least discuss) quite a lot of problems that bothered us for ages. One of the most important issue was the UI design for which we have now more-or-less clear vision and even the prototype I wrote in Ruby in a couple of minutes. Once I'll find time to transfer the vision to paper (or rather email) it will appear at kdevelop-devel mailing list for discussion. All I can say now is that it seems we found rather cool compromise between UI simplicity and feature-full bloatness. What we did is basically we tried to find an intersection between ideas behind MacOSX's Finder and XCode, Eclipse's perspectives and splitted-tab layouts, KDevelop's Ideal toolviews. Such an intersection while not being radically innovative (like ZUI, for example) will hopefully give us a powerfull UI that no IDE has.

Of course, UI ideas were not the only thing we produced at aKademy. kdevelop-pg parser generator has been pushed to its full extent because Jakob started to (re)implement c++ parser with it. Adam put a lot of work to solidify the our code models stuff, and also I started to write a new model-based filemanager (already in trunk). Lot of other things happened too which I can't remember right now (probably because I spent many nights partying in Irish pubs;)).

Another thing we decided upon is that we're going to have a KDevelop conference/hacking session next year. We had it back in 2005 but missed this year and we certainly don't want to miss another year. So during KDevelop BoF it was decided to try organizing such event in mid-summer 2007. At this time we know of two possible candidates for the location. One is Boston, USA and another is the south cost of Crimea, Ukraine. In both cases we'd need some sponsorship so if you know how we can get it I'd much like to hear about that.

After aKademy I spent three days travelling the Ireland. I visited Killarney and made my way through The Ring of Kerry, I was in Cork and saw the Blarney Castle and I spent a day in Galway and Aran Islands. I got too many impressions to describe all them here. What I can say is that Ireland is certainly one of the best places of the world I ever visited.

In Qt 4.2 trolls did amazing job at improving dockwidgets. They even added the tabbing feature so that you can group docks into the one tabwidget by just dragging one on top of another.

A couple of months ago I thought that would replace "Ideal buttonbars" - those groups of buttons you can see in KDevelop and Quanta in Ideal UI mode at the window borders. But today I think that buttons should still stay if we want the Ideal mode like we had before. We just don't have enough control of those new tabs and can't make them do what we want (i.e. hide toolviews). Also they seem to be always horizontal which is a pity because we got used to vertical rows of buttons.

So, this and this is how KDevelop4 with toolviews looks now. Notice that KDevelop4 looks exactly like Qt Designer - all toolviews are just plain dock widgets. And this is how Ideal mode looked before. Notice the "button bars" at the bottom, left and right window sides.

The question now is Qt Designer-like interface good enough or is it better to back to good old Ideal UI with buttonbars? I don't have the good answer, please share your opinion with us at kdevelop-devel@kdevelop.org or just leave a comment here.

For now I'll continue working on new Ideal library. I miss Ideal too much ;)

Yes, I'm back after not committing for a month and I'm back with the new ruby parser for KDevelop. The parser is of course not finished and it barely parses simple ruby code but it is there. I'm looking forward to implementing some real ruby language support features. First will most likely be a code model (which will automatically give nice code view with classes, methods, etc.). As it turned out our kdevelop-pg parser generator framework makes it dead easy to do that. And its not only the kdevelop-pg that helps, the whole KDevelop4 architecture makes the process a lot faster.

Previously when you wanted to implement the language support in KDevelop, you should have done:

1. lexer to tokenize the source


2. parser to transform the token stream into the AST


3. AST walker to make it possible to do something with it


4. AST parser to create the abstract code representation - the code model


5. "background parser" to execute the parser as a background job and fill the code model


6. language support part to run the background parser

Today you still have to write the lexer and the parser, but you no longer have to care much about the AST and AST walkers(visitors) because they are generated for you. And once the code model definition file is written, the entire code model will be generated too. kdevelop-pg does all those things.

From the other side, KDevelop4 has more generic language support and abstracted background parser so you can just tell the language support in several lines of code to use your parser. There's no need for language support code duplication which was so common in KDevelop3.

Simply put, points #3 and #5 are automatic now, #2, #4 and #6 were made easier. At this point I'm wondering if it is feasible to eliminate the #4 completely, i.e. implement automatic generation of code model binder which traverses the AST and fills the codemodel with items.

From what I can see KDevelop4 will really shine in the area of language supports. blackarrow is doing wonders with C++. jpetso completed his summer-of-code csharp project and the excellent csharp support is already in SVN. manyoso added java support that uses the complete java parser jpetso created last year. And if we add up language-neutral refactoring (which was another SOC project) to the stack, we would get the idea of how cool KDevelop4 is going to be!

It doesn't look like I'm short of cool material for my aKademy presentation :) Rock on, KDevelop!

It does look like I've finally reached the state where my job became my passion. You doubt it's possible? I have a counter-evidence :)

From this very moment Pluron company is starting sponsoring me to work on KDevelop. I'm allowed now to spend part of my work time on KDevelop! That's so increadibly cool! We'll make the announcement soon, but I can't wait to tell about that ;)

In Pluron we develop Ruby/Rails project and of course use KDevelop as our IDE, so my primary target would probably be to make KDevelop4 shine as a Ruby IDE but of course I'll continue my work on UI and other things. This is a good chance to make all the difference ;)

Thanks to Pluron and special thanks to Gleb Arshinov, company founder and great open source supporter who made this possible!

PS: this is a shameless plug, but if you live in Ukraine, passionate about open source, ruby and/or ruby on rails or just look for a cool place to work, consider joining us ;)

Yesterday night was one of those rare productive KDevelop hacking nights. Last time I had it several month ago. Looks like I'm getting older ;)

Anyway, I managed to finally introduce "good-enough" keyboard navigation for KDevelop UI. Changes went to the Simple Ideal UI mode (which is now default in KDevelop 3.4).

Of course, you have Ctrl+Alt+Shift+(B|R|L) keys to activate toolviews at the bottom, right and left. But contrary to KMDI, if the toolview is already active and not focused, it will just get the focus, and not close. Also Alt+(Left|Right) is used for both toolview and editor switching depending on which of those have focus.

That's not everything, of course. You can right-click at the toolview button and assign an accelerator number to it and switch to and from the view using Alt+<Number> shortcut (like in IntelliJ IDEA).

I'm not sure those changes solve all keyboard navigation problems we have, but at least 3.4 is going to be an improvement in this area. Expect better UI navigation model from me only for KDevelop 4 ;)

PS: did I say that Simple Ideal will store the toolview layout (opened/closed state, sizes) ;) ?

Looks like this time we did it right! KDevelop will have 3 summer of code projects contrary to only 1 last year :) This is awesome!

The overall number of KDevelop applications was 15 and 5 of them were inside the first 50. The interesting thing is that 6 proposals were aimed for "C# parser/integration". Ok, people, we finally began to understand. You need C# support in KDevelop, the thing we (KDevelop devels) has not been paying attention to for several years ;)

I wish we had higher limit for KDE projects, but in any case it's great to see 24 nice applications approved! Thanks to Google again!

Ok, now back to work. It's going to be a "hot" summer for me cause I'm mentoring two of our three students. Another one goes to our 4.x series maintainer Matt Rogers. Carsten Pfeiffer, Vladimir Prus and Andras Mantia kindly agreed to help us as co-mentors. Thanks :)

The deadline for Google SOC applications is really soon (TM) so I'm here to invite you to join KDevelop team this summer and have a lot of fun!

We have a lot of interesting proposals in our website for you and apart from C# support they are all still free.

If you are student, KDevelop user and know programming - join! Don't worry about KDevelop codebase being large. It's modular and we will give as much help as we can.

The greatest project proposals are "Unified code/header editing" and "Next-gen version control" but you're free to make your own. Everything that is about programming language parsing, code completion and refactoring is always welcome! Support for a build system of your choice also looks like a good project to hack on.

Oh, this competition project turned out to be very fruitful! I wish we could do that kind of UI design competition for KDevelop. For now we don't have $1000 but I do appreciate everybody sending me their ideas of IDE design and workflow ;)

Yesterday I attended annual OSDN.UA conference in Kiev, Ukraine. I was talking about KDE4 technology and plans.

I couldn't resist speaking about KDevelop a bit so I revealed some KDevelop4 information ;) Most common questions were "why are you replacing of autotools?" and "what will happen with multimedia?".

After the talk I was communicating with the people and here I'd like to present a short summary.
First, KDE users asked for a simple way for them to participate in writing documentation. What they did ask IMHO was like offline wiki engine for KHelpCenter. They'd like to be able to put some notes and text into the offline documentation. For example, KDevelop/Automake documentation section is unfinished. Users say they could have finished it (or at least write several centences just to share their experience). But currently they'd need to either modify docbook sources or figure out a documentation maintainer and send him an email with a text. What would users love is a way to put some text/comments into the documentation and then click one button and send a patch with their changes to the documentation maintainer automatically.

Also I talked to ReactOS developer. He said they'd like to have Qt/KDE compiled and used as a default desktop on their operating system. They're compiling the system with MinGW32 compiler so I think Qt4 should work and KDE4 should work as well (when ported to win32).

Thanks to Adam and Ariya the topic is hot now so I couldn't resist commenting it :)
From what I can see, they're trying to:
1) get rid of menus
2) get rid of modal dialogs.
I completely support those two goals. Heh, I should have shown those of you who were in Malaga "kdevelop4geeks.ui" file that has been lying on my desktop for more than a month ;) That file is the concept of KDevelop4 user interface I created before I heard about MS Office 12. First version of it didn't contain menus at all and second included a "Menu" button just where the "File" menu is in MSO12. Other concepts I was playing with were different though. Anyway, most of them were efforts to move most of functionality from dialogs to views inside the main window which coincide with the second effort of MS guys.

Thus said, I have to admit that we should probably not copy their interface, at least not in KDevelop. I've only looked at screenshots so I can be wrong here, but it seems their interface is designed for mouse users. Contrary to that, I'd like to see KDevelop interface completely navigatable by keyboard. More, I'd like to make keyboard navigation the prefferred way over mousing. Therefore it's more likely we have to invent a different UI.

Anyway, I'll try to gather my UI ideas and blog more about them soon.

Finally it looks like I'm good to go to aKademy. After 3 visits to Spanish embassy (which is 600 km away from my home), 4 days of making phone calls to the embassy trying just to arrange an interview and 2 days of calling to know the result, I was told that I have my visa. Whew :) Now I just need to go to the embassy and take my documents back.
Also thanks to Trolltech (thank you Harald! :)) and KDE-eV (thanks Mirko and other guys :)) my travel expenses will be reimbursed.
That's going to be cool :) I will be able to spend 5 days (till 1st September) hacking on KDE-Eclipse (I'm starting to like that job;) but that's another blog) and other 4 days hacking on KDevelop4.

Today and yesterday I was doing like a real tourist. I visited lots of places in the city, walked tons of kilometers. At the end I got tired but very pleased. Ottawa is a really beautiful city and it doesn't look as other cities I visited :) Cool!

I finally visited America :) Look's like it's a cool place but anyway it's a lot different from Europe. Especially the wet climate makes me feel that the weather in Ukraine is not so bad ;)

I had two talks - one at the DesktopCon and one at LinuxSymposium today. Looks like the one at DesktopCon took more attention. At LinuxSymposium I had two hours for the tutorial. At the first hour I was talking about KDevelop Platform mostly and I had some people interested in the platform stuff we have. Looks like we have to promote it more and try to get more applications written for the platform just to make a really good showcase. The second hour was scheduled after the lunch break and I spent it mostly discussing technical issues with the Eclipse guy (who was KDE developer some time ago btw :)). Other people were not interested in the talk.

Commenting Mathieu's blog, I have to disagree on some things with him. The organization of the conference is ok. I had my two tutorials accepted and we could have more KDE talks accepted if we sent our proposals. But I also have to agree with Mathieu that people who attend this conference are not really interested in KDE technologies. I don't know why - that's probably beyond my understanding. Anyway, there were some cool talks about Eclipse, Kernel (today) and even some X-related talks were ok ;) (we had lots, lots of X talks).

Today my trip to Ottawa is starting. I will give two tutorials - one at DesktopCon (19th) and another at LinuxSymposium (20th). Guys from Xandros were so kind to make this possible by sponsoring me :)

PS: Another thing everybody is wondering about is where is KDevelop Conference dot story. Well, once KDevelop4 is commited to svn, the story will be there ;)