[dot] Kommander Looks to Shake Up the Desktop

[Dot Stories]

URL: http://dot.kde.org/1087424515/

From: Eric Laffoon <sequitur at kde.org>
Dept: and now for something completely different
Date: Thursday 17/Jun/2004, @00:21

Kommander Looks to Shake Up the Desktop
=======================================

     Kommander [http://kde-apps.org/content/show.php?content=12865] 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 produces 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
[http://quanta.sourceforge.net/main1.php?actfile=donate] 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"
[http://kde-apps.org/content/show.php?content=12852], 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 uses 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
      implimentation 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
[http://quanta.sourceforge.net/main1.php?actfile=donate] or develop
[http://mail.kdewebdev.org/mailman/listinfo/kommander-devel] 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 [http://mail.kdewebdev.org/mailman/listinfo/kommander] and
donating [http://quanta.sourceforge.net/main1.php?actfile=donate] or
developing [http://mail.kdewebdev.org/mailman/listinfo/kommander-devel]
with us.