Kommander is on its way to become one of the most compelling tools in KDE. It has elements that should be very interesting to application developers, power users, newbies and companies looking at using the Linux desktop. So the answer to the question many of you may be asking, "What is Kommander?", really has to be answered from each perspective. A simplified technical description is that Kommander is two programs, an editor and an executor, that produce dialogs that you can execute.
What is interesting is that they can require virtually no scripting languages to produce a result, or you can use the scripting language of your choice. Internally everything is done with DCOP. What is even more interesting is that soon Kommander will not be limited to dialogs, it is easy and fast to build programs with and the internal DCOP executes extremely fast. Kommander could become one of the most exciting things to happen on the desktop ever when combined with existing KDE technologies. Currently most Kommander development is done by Michal Rudolf who is sponsored part time by the Quanta/kdewebdev sponsors.
Let's look first at how Kommander can impact newbies. As a newbie you could grab a Kommander program, for example my "Simple Installer", and install it with great ease. This is because it doesn't have to be compiled first, but it also doesn't have binary compatibility issues with libraries because it's not binary. Kommander usones functionality compiled in using DCOP. The executor is more of a pre processor than an interpreter. So internally everything happens just about as fast as a compiled program. As we add the capability for main windows, toolbars and menus to our projects it will continue to be very easy to grab a program, install it and run it. The only thing you need is KDE and the Kommander executor installed. This bypasses binary RPM issues as well as problems for people not prepared to compile from source.
For users Kommander adds something interesting. You can edit Kommander applications in the form they are run in since they are not compiled. Using the Kommander Editor you can make changes to an application you have downloaded or create new ones. You can also use the DCOP capabilities to extend your existing KDE applications and communicate with them. This makes it possible to merge your KDE desktop into your own personal super application with custom dialogs and DCOP. If you're unfamiliar with DCOP try running kdcop.
Power users who are knowledgable about how programs work, but perhaps lack the time or skills to program in C++ now have a new option. Sure you can find the script language application you want with bindings, but that has limitations.
A power user can use Kommander's built in functions or easily shell out to the language of their choice. The language can interact with the application through calls to Kommander's special instructions which are parsed before sending it to the script interpreter, and by DCOP calls. However with Kommander's specials it is unlikely that you will need to use scripting for 80%-90% or more of what you have to do in even more complex tasks, unless you want to. This means that Kommander opens the door to application development to an admin level user! The potential for the growth of applications with Kommander is unprecedented because this opportunity has never been opened so widely, and Kommander is a very easy and productive environment. Also the widgets are very easy to add from KDE widgets as plugins so even a beginning C++ coder can add a widget.
So what does Kommander do for developers? Put them out of work? Hardly! Larger applications will probably always be compiled, but Kommander offers them some interesting things they never had... With Kommander developers can take a feature that is difficult to define and offer a user extensible component. An important fix or addition can be offered outside of a release schedule that users can download and run without having to compile. Developers can also prototype on Kommander, and even distribute features in development to testers who can submit working GUI alterations for refinement of the development cycle. In fact, since Kommander uses XML files developers could even create dialogs on the fly when the application runs.
Clearly Kommander has some amazing potential, but it's not ready to realize all of it just yet. We hope soon. Michal Rudolf has been sponsored part time for Quanta and Kommander and is largely focusing on Kommander right now. The possibility of sponsoring him full time as well as getting more volunteer developers would make this task a lot easier because there is a lot of work. Maybe you would like to get involved helping us to sponsor or develop Kommander. Now let's look more briefly at how Kommander works.
As you may have guessed Kommander is not your usual tool. Typical application design starts with a concept, translates it into a language and this is translated into the application. If you've ever had difficulty expressing yourself you've experienced the problem with language. It adds complexity to concepts. As the saying goes, a picture is worth 1000 words. Development using Kommander takes a more conceptual and visual path, intentionally minimizing the constraints of language. Kommander supports object oriented design by it's nature as all data is bound to objects. Kommander stores information in widgets (GUI elements). So if you have a LineEdit you want to call "mystuff" you would reference it internally with @mystuff. When you ask for @mystuff, whatever has been entered into the mystuff widget will be returned. In this way you can create strings. For example, if @mystuff = "Hello" and @morestuff = "World" you could have a button with the value "@mystuff @morestuff!" Which would return "Hello World!". You really have to play with it to for it to suddenly dawn on you how simple it is. Reading about a conceptual visual tool is much like trying to get a picture through a radio. Kommander does not have a scripting language in the traditional sense. It uses custom functions called "specials" that begin with an "@" like @dcop() and it uses DCOP to control it's widgets. Our focus has been to keep Kommander specials easy to work with by using consistent naming (some will be renamed shortly for consistency) and groups where ever possible. Eventually we will have a function wizard for them too. As an example of groups, in CVS we have a new @String special. You can access it's functions like so @String.length("@LineEdit1"). This would return the length of the contents of LineEdit1.
So the question is what can Kommander do and what still needs to be done? Currently we're releasing a new Alpha every weekend. It is an Alpha because it introduces new features, but it's usually stable enough for production work. Kommander is fairly simple internally so stability is not generally an issue. Here is a list of some of Kommander's current features.
Kommander has a number of things in work right now including KPart creation, a KPart loader, project tools, enhanced plugin widget capability, KStuff repository and more. As soon as plugins are brought to full capability we will be adding database widgets too. Hopefully very soon you will be able to load a Kommander program and if it does not have a widget it will tell you and ask you if you would like to search the global repository and get it.
To bring Kommander to where we want to will take a lot of work, but we hope we are on track for KDE 3.3. It will need i18n functionality, new widgets and the editor needs to be improved or rebuilt. There is a much longer list of things to do than what is done and we really need help doing it. I hope you'll consider helping by testing, feeding back to our list and donating or developing with us.