Kommander Looks to Shake Up the Desktop

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.

  • You are limited to the functionality built into that IDE by the developers for that language.
  • The application actually creates the elements of the GUI and does everything using the script language, so the difference in speed with Kommander is not applied just to the data but the application structure as well.
  • You are limited to that language, and potentially just that implementation of it for your application.
  • Importing widgets may not be that easy at all.
  • Team development with people scripting in other languages is impractical if not impossible.

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.

What does Kommander offer a company looking at Linux on the desktop? It's been estimated that over 80% of software is custom made and not shrink wrapped. For a company looking at desktop applications the odds are excellent they will need to have some custom applications done for their business services. Commercial applications rarely fill the bill for companies. The odds are good they already have custom applications developed in various languages with various tools. They probably also have in house programmers familiar with Basic, Pascal, Perl, bash, Python, Java, Javascript, even Rexx. What's great about Kommander is that any language that can be run in a shell can be used. This means some code can be reclaimed and developers can be more productive. It is also probably the fastest easiest platform they have ever worked with. Most significantly it removes all traditional limits and obsolescence as applications are modular and they can transition languages as well as augment features with any language skill set.

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.

  • Full manipulation of existing widgets with DCOP
  • Environment special @env()
  • Global variables for the window process
  • Reading and writing of settings on a per widget basis
  • Associative arrays
  • Special DCOP information for interactions like parent pid
  • Execute shell process or script in any language
  • Warnings for incorrect setup
  • String functions
  • File functions

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.

Dot Categories: 

Comments

by Matthew C. Tedder (not verified)

If that were true.. we should have "list" instead of "ls" and ruin every other short-hand that makes shell so quick to use..for the experienced.

Kommmander's "kmdr" short-hand is quite intuitive.