\NewEntry 0 GUI \NewEntry 1 Widgets

Widgets available in Kommander

\NewEntry 1 Editor

Layout of Edit Kommander Text dialog

Old ideas:

\NewEntry 1 Usability \Link knowit://Source code

Various GUI-related features (outdated, KDE3 version will not be changed)

\NewEntry 1 Run/debug

Running/testing inside Editor

\NewEntry 1 DCOP browser

DCOP browser (preliminary ideas)

\NewEntry 1 Other

Other GUI-related issues

KDE4 ideas:

\NewEntry 0 Bugs

Various bugs to be fixed

\NewEntry 0 Help \NewEntry 1 Documentation

Kommander tutorials, documentation etc.

\NewEntry 1 Examples

Examples to be used with tutorial

\NewEntry 1 Scripts

Kommander scripts that can be useful

\NewEntry 0 Language \NewEntry 1 Syntax
  • Syntax-related problems
  • \NewEntry 1 New functions

    New functions that could be useful

    \NewEntry 1 Script languages

    Using script languages other than Bash

    If we keep the old parser.

    Make it possible to use any language with Kommander. The idea is to replace Kommander specials with language specific code in a way that it will not break conditions and loops, like now. example:
    array="1 2 3 4 5"
    for i in $array do

    This does not work now. The idea is to replace @Widget.method() with a language specific DCOP call.
    If the language has DCOP bindings, use those bindings to execute the dcop call. If not, use the command line
    DCOP application. This is slower, but always works. In the above case, Kommander would replace
    dcop kmdr-executor-PID KommanderIf setText Label $i

    Kommander will have description files for each supported language about how to execute DCOP calls.
    If the language has DCOP bindings, this description tells the syntax of the bindings. If it doesn't have, the description gives a way how to execute external applications. This should always exists, as all languages can execute external applications.

    In KDE4, of course use DBUS instead of DCOP.

    \NewEntry 1 Aliases

    Aliases - easier access to Kommander features

    \NewEntry 1 Signals

    New Q_SIGNALS for existing widgets

    \NewEntry 1 Parser

    Features of new parser

    \NewEntry 0 1.3 release prep 2008 \NewEntry 1 To Do

    Kommander Release Do list

    \NewEntry 1 Eric's To Do \NewEntry 1 Supplemental \NewEntry 1 investigate

    Things to look into

    \NewEntry 1 Bugs to squish

    Version 1.3 FIXME list

    \NewEntry 1 Done

    New widgets include the DatePicker, Popup Menu and Toolbox. New functions inlcude widget creation, hooking and unhooking Q_SIGNALS and Q_SLOTS and full slot access as well as passing and returning parameters in scripts. WooHoo! Take that do list!

    See changlog for more complete list

    \NewEntry 1 Won't Do

    The Kommander editor is effectively dead for KDE3. Porting is senseless as it is an old Qt Designer hack. Since Designer for Qt 4x is actually designed this time to be easy to extend and modify the first generation of the editor will be scrapped.

    Other parts of Kommander like the parser should be much more portable.

    - creating table widgets means if you need to know the calling widget you need create scripts on the fly for this.

    \CurrentEntry 0 KDE4 prep \NewEntry 0 Executor

    Executing Kommander scripts

    \NewEntry 0 Refactoring, other ideas

    Kommander source code

    \NewEntry 0 Last changes

    Last changes in TODO file

    2004-05-28, 17:35

    2004-05-14, 12:44

    2004-05-08, 23:00

    \NewEntry 0 Done
  • ChangeLog of Kommander
  • See ChangeLog file for details and dates
  • \NewEntry 0 About this file

    This file should document both what should be done in Kommander and what was done.

    All entries marked with a date without an author were made by Michal Rudolf

    When adding something important, please enter it in ChangeLog or Done and mark it with current date (in yyyy-MM-dd, hh:mm format) and your name.