Kommander Kommander writings
An introduction to Kommander
- By Eric Laffoon
The beginnings of Kommander
Back during KDE version 2 Quanta Plus was moving along nicely and I was in web editing nirvana, but there was something missing. I wanted to be able to extend Quanta without any waiting for code to compile and test. I tried a program called Kaptain which was a text based tool written as a demonstration of language parsing. Actually I saw it and thought it was a great idea... and six months later I finally tried it. The need to write a text file was a turn off and I didn't really visualize what could be done. Shortly I was doing things the author had not thought of. Marc Britton got involved to help update Kaptain for KDE 3 and Marc came to the conclusion that a new tool based on Qt Designer would be better in so many ways. Of course developers never really think of how difficult it will be, but Marc finally got it done. Kommander's initial release did little more than manipulate text strings by putting slices of them in widgets, and a little bash. Yet that was a revelation for many.
Enter Michal Rudolf. Marc got too busy and Michal was sponsored part time. Michal and I had had some ideas. Actually Andras Mantia did some early DCOP and Marc did the populate function. Michal took Kommander to the next level with extensive DCOP, new widgets, finishing Marc's plugin code, the Function Browser and finally a new parser. Kommander does a lot now, but for some people the question remains... Just exactly what is it and what can I use it for?
Kommander is a small to medium application builder
You can create applications based on dialogs, wizards or MainWindow applications with menus and toolbars. MainWindow applications are a little more of a pain at the moment as some functionality has been removed from the editor. Kommander uses DCOP in KDE 3 and will use DBUS in KDE 4. Our testing reveals that the average several year old computer can do several thousand DCOP operations per second, so we're talking pretty fast for all but the most demanding uses. It's how Kommander goes about doing what it does that makes it so exceptionally interesting. Kommander uses the Qt/KDE code to convert an XML *.ui file into a workable window. Consider that this is what is using code used in C++ KDE programs. If we were using a scripting language what is the first thing we'd do? We would write bindings to allow it to draw windows and widgets. Hey, interpreted languages are inherently slower to execute than compiled programs and much of the errors and development time is in repetitive work on the GUI. So in this way Kommander is more like a compiled program and it uses DCOP functions which are compiled, but using it is more like a scripting program. The most interesting thing about this is how amazingly small a simple dialog is and how few lines of code it takes to do something.
So Kommander is inherently fast and light compared to interpreted languages with bindings. What if you like your favorite scripting language. Join the crowd. The big problem with GUI scripting is that the IDE I like is for another language and the language I like doesn't have good tools, but I'm not going to learn yet another language to use a tool. In fact these tools rise and fall on the whim of a small developer base. Don't get me wrong. KDE has some great tools and sharp people working on them, but no matter how they try they will not convert people from Python to Ruby or Perl to PHP, or name your own. I like Rexx. The inherent problem with binding a language to GUI tools is that there will never be a critical mass of development on any given language because there are so many. We set out to make Kommander language neutral. We almost succeeded. There is one problem. To truly accomplish this all languages would need DCOP bindings. However we have it in some degree. In order to deal with asynchronous operations of Kommander and your shell script we have to have a central control of the application with Kommander. We even developed a very simple neutral basic scripting language to offer simple functionality to non programmers or logic structure to programmers. So you could be a Python guy, and have a friend who does Perl, another with bash and another with Ruby and you could all divide up different parts of an application and build them. If you were using a DCOP enabled language you could replace the Kommander script with your own and just control the application with DCOP. We have a Function Browser to make it as easy as using the KSpread function builder to make function statements in Kommander. That can also be extended for other languages. Our goal is to attract developers with different preferred languages and have them help build functionality into Kommander for all those languages. This means Kommander dialogs will never lose when the next language becomes more popular.
What can you use Kommander for?
That's the great part. Kommander is not being developed for developers, (which may be why some developers "don't get it") it is being developed for the average user. That's why we have a point and click function builder, and I still use it because I have too many things to remember than to prove how manly I am blindly typing arcane syntax. Kommander is great for little personal stuff. I use it to keep track of number sequences I use for an online random number drawing for my business. I made a photo browser to add pictures to my project. I was most impressed that a complete non programmer developed a very successful application. However Kommander is also for developers. Quanta Plus has used it for the HTML Quick start dialog for some time. As a developer we can use i18n translations with Kommander dialogs and we can offer updates instantly as well as interfaces users can easily refine and send us revisions on. Kommander simply takes power from the existing structure and moves it into new freedoms for all of is.
Where is Kommander going?
Michal and I joke that KDE 5 will be built with Kommander. Seriously, we are looking for a lot of enhancements including creating and loading KParts, context menus, KActions, script parameters and numerous enhancements. However the biggest advertisement is that we're working to make it easy to extend Kommander with Kommander. Our goal is to make it so that a lot can be done with Kommander and mostly internals, widgets and language parsing is done in C++. We will be integrating KStuff so that you can have a Kommander application that uses resources like data and when a user runs it the application will detect if they are missing required data and ask permission to retrieve it for them. Applications could even check and tell users when updates are available. People writing Kommander applications could share resources easily. This means we could have a community of users developing tools and sharing them without ever having had to get involved in the development process. Consider that.
We think Kommander has the most exciting prospects of any new tool because it can be homogonized into so many development languages and uses. Our hope is to get the executor into the kdebase packages for KDE 4 so that everyone will be able to run Kommander extentions. We also hope to persuade developers to enable Kommander to be the tool for creating GUI extentions and scripting for their apps. If you are interested in helping us please contact me. Also keep in mind that our development requires funding to sponsor enough time for serious work.