Cmdr Kommander

Kommando-Installer RoadMap

2006-09-28T21:34:00.000-07:00

Kommando-Installer-0.6.2

Kommando-Installer Preference Tab
Split Kommando-Installer and Data into 2 packages.

Kommando-Installer-0.7

Logging Tab

Kommando-Installer-0.8

Commercial Update Button
Custom Update Button
Kommando-Installer Update Tab

Kommando-Installer-0.9

Kommando Help Tab

Kommando-Installer-0.9.1

SLAX Modules Descriptions

Kommando-Installer-1.0
First Official Release

Kommando-Installer-1.1
Start developing the Dependancy and Prerequisite Framework

Kommando-Installer

2006-09-28T21:10:00.000-07:00

Kommando-Installer Progress

Status of each Tab
Commercial Tab
Works
Install Package Button
Install All Packages Button
Search Filter
Descriptions
Module Install Location function

In Progress
Nothing in progress

Not Working Yet
Dependancy and Prerequisite Check Boxes
Update List Button

SLAX Modules Tab
Works
Install Package Button
Update List Button
Module Install Location function [in progress]

In Progress
Nothing in progress

Not Working Yet
Dependancy and Prerequisite Check Boxes
Descriptions - Need a list of descriptions from somewhere... How to approach this...

Custom Tab
Works
Install Package Button
Install All Packages Button
Search Filter
Descriptions
Module Install Location function

In Progress
Nothing in progress

Not Working Yet
Dependancy and Prerequisite Check Boxes
Update List Button

GPL Tab
Not Working Yet

All Tab
Not Working Yet

Search Tab
Fully Functional

Logs Tab
Fully Functional

Kommando Tab
About SubTab
Fully Functional

Update SubTab
Not Functional

Help SubTab
Not Functional

Preferences SubTab
Not Functional

Progress so far...

Fine tuning of the Package Profiles.
Worked on making template Package Profiles.
Sample Commercial Installers work (GoogleEarth4, RealPlayer10, FlashPlayer7, JRE1.5.0.06)
Updated SLAX Module Master List.
Added 3rd form of ftp to install qualifiers. Now there are conf, ftp, http.
For Commercial Tab: added Module Install Location Box with custom option box, /tmp, and /boot/modules Radio Buttons.

Need to add:

Interrupt Traps for scripts for clean up
Add space calculation
Add package multi-select
Dependancy and Prerequisite CheckBoxes don't do anything yet.
Nothing in the Kommando Tab does anything
GPL and All Tabs dont have anything in them.
Update buttons on Commercial and Custom Tabs need to function.
Prerequisite and Dependancy Checkboxes
Help Button and Help Tab
Kommando-Installer Preferences Tab

Kommando-Installer Progress...

2006-09-22T09:01:00.000-07:00

Kommando-Installer Progress

Progress so far...

Cleaned up Package Profiles to make them as generic as possible.
Worked on making template Package Profiles
Sample Commercial Installers work (GoogleEarth and RealPlayer)
SLAX Module Selection Download and Install works.
"Quick Search" Filters working
Search Tab Working with 4 options
Update still in the planning stage...
No Help Feature yet
"GPL" and "All" Tabs do nothing currently
Thought of Creating a Package Creation Tool to help make Kommando-Installer Package Profiles.
Added "Custom" Option so you can put in your own List of software with its own tab, that way your software library can be made available and its list/package updated independantly. [Not quite functional... but very close]

To Do

GPL and All Tab
Get Custom Tab fully operational
Make a global variable list and take out all hard coded references
Create a settings file
Enable Help function
Error checking
Get Update function working... some changes in the interface may need to be done to make each Tab capable of updating its own lists and options.
Create a Preference Tab

Widget Playgrounds

2006-09-14T07:06:00.000-07:00

Widget Playgrounds are little test programs to learn and experiment on Widget capabilities and an environment's command parser.

In some coming Blogs, I will create some Widget Playgrounds (and post them somewhere) to show how to use Kommander Widgets and the Command Parsers capabilities.

Kommander Documentation Resources and My Methodology

2006-09-14T05:43:00.000-07:00

I have gotten a few e-mail messages asking how I have figured out a lot the Kommander stuff since there is very little "formal" documentation.

Well , there are a few resources I have used and a specific mentality I have used. First there are the resources I have used and second there is the Methodology I use.

Kommander Docuementation Resources
I use the following: The Kommander Handbook, The Kommander Mailing List, Kommander Mailing List Archive, The Function Browser, The Widget Reference.

The Kommander Handbook which contains some good reference material but is in need of updating. I STRONGLY STRONGLY STRONGLY urge the Kommander developers to make a Wiki for Documentation, since that could put many people into the documentation arena. I have thought to create one myself but lack the broadband servers to make it practical. KDE is already setup for such a thing (KDEmedia Wiki), so I am not sure why it has not been done.

I understand that the developers are very busy and documentation is the last thing on their minds. But the only way for people to USE and UNDERSTAND what Kommander can do is to document it. For instance, on the Kommander Home Page, the Widget References could be put in the FAQ or on its own page. I had to find it via google.com from the mailing list. I have a Widget Reference Blog entry that currently mimics the Mailing List one but I plan going through it to validate its contents and to actually make a tutorial for each method entry.

The Kommander Mailing List is a good resource for information. You can ask questions there and the main developers for kdewebdev and Kommander will answer your questions. The mailing list concept is quite archaic even though USENET (deja) can be used to search through them provided they are submitted to a USENET group. I recommend the Digest format emails when you sign up. That way you can use a digest reader to sort though the threads.

The Kommander Mailing List Archive section of the Mailing list can be quite helpful but take note, from time to time it doesn't have all the back months and the FULL archive link does not always contain everything. Never-the-less, it is a very good resource. I wish they had the Archive in Digest Format so you could use a Digest Reader to sort through it all but I will try looking at the file with an e-mail application to see what that yields.

As an improvement, instead of the mailing list approach, I recommend a forum format, since it is a bit more modern of an interface, and depending on the forum used, the searching can be quite helpful. Also, an improvement to the Archive section would be a search function. Granted you can download the master archive yourself and look through it but a search engine facility is much better for complex search requests.

One last complaint related to the "Mailing List". My impression is that the overall mood of Kommander Application/Applet development is that if you really want to know how to do something, post to the mailing list. I am not a strong believer in that philiosphy. I think almost everything that needs to be known should be in the handbook, and the developer talk/bug discussion/feature enhancement/I can't figure this out kind of discussions should be made on the Mailing List. I should NOT have to go to a 2 year old Mailing list Archive entry for the complete Widget Reference.

The Function Browser is built into Kommander. When you Right Click pretty much anywhere on the Kommander Canvas and choose the "Edit Kommander Text..." menu option, an "Edit Text" box appears. In the Lower Left corner of that Window is a Button called "Function". That is the Function Browser. Visit it, use it, learn to love it. It is your friend. It contains many helpful references for Arrays, dcop, file, input, Kommander (parser key words), message and string functions.

The usage text given is rudimentary BUT that I am sure will improve and get much better. There may be some functions missing (I did not notice) but if there are I am confident they will be added in the coming Kommander releases.

The Widget Reference as mentioned before. Also My Widget Reference which currently is just a mirror of the Mailing List one but will get more in depth at some point.

One area of improvement would be a Widget Method Browser. Currently such a resource does not exist.

Kommander Examples In the kdewebdev distribution there are example files that do specific Kommander type things. These include progress bar, status bar, ListBox population, Argument Passing to a Kommander program, global variable, just to name a few.

Improvements: Forum based resource; A glossary- Describing the "Lingo" Page, Widget, method, etc.; A Widget Reference or a Widget Method Browser.

The Methodology
The Methodology I use is the same approach I use to programming. I make little "programs". For Kommander, I create what I call "Widget Playgrounds." The Widget Playground can be as simple or as complex as you want or need them to be. I think of a project or a task for motivation, then I create a playground to experiment in. If you want to know about Buttons, make a Button Widget Playground. This playground would include; Radio Buttons, Button Boxes, Execute Buttons, Close Buttons, Check Boxes, etc. Then you make the Buttons "DO" things. You may have to put other widgets in your playground or you may just choose to output the action to a text file.

For instance You may create a Execute Button and a ListBox. When you click the Execute Button, you put the output of a unix command into the ListBox.

As a quick example, In the Edit Text Default Window for the Execute Button, you would put
@ListBox_Name.setText(@exec(ls -l/bin))
That will use the @exec function to do an "ls -l /bin" and then the .setText method of the Widget will put that content into the ListBox called ListBox_Name.

I will have a series of Blogs describing Kommander Widgets and the Parser and the will be titled Widget Playground:

Kommander Project Forensics: NetWizard Part 1

2006-09-13T19:43:00.000-07:00

Using an Init Screen, Layers, dcop, and the Next Button

Disclaimer: I use Kommander's kmdr-editor and kmdr-executor 1.2 Using an older version that that WILL result in some example NOT working.

In a project I am currently working on, NetWizard, I have wanted to do some slick types of things so the interface does not detract from the Wizard process.

What is NetWizard? It is a Network Configuration Wizard that currently supports configuring ndiswrapper drivers for SLAX Linux. Kernel Driver configuration is in the works and will be released in the future. What is SLAX Linux? It is a VERY slick "Linux Live" distribution based on Slackware created with Linux Live scripts author. The resulting distro is SLAX. There are many other varients using Linux Live scripts and all have a similar need- a network configuration tool that will create a "Module" that sets up the network connection at boot time. Out of this need, I set out to create a Configuration Wizard- and NetWizard was born.

I started out using kdialog, then quickly began looking for a better solution. After a bit of searching and trying out some other tools, I chose Kommander. Here is the first of many articles discussing a forensic look at NetWizard.

The Beginning
I wanted to have a Startup Screen... easy enough. I just set up page 1 as an informational screen describing NetWizard. This gave me a great opportunity... I can use this screen as a Wizard Initialization screen. How do you do that? Here's how.

The Init Screen.
The concept is simple. Create a pixmap on page 1. Call it InitScreenPixmap. Then create a ScriptObject and call it InitScreenScriptObject. Place all your initialization type actions in InitScreenScriptObject. Then create the following Connection using signal/slots:
InitScreenPixmap:widgetOpened:InitScreenScriptObject:execute()

When the Wizard starts, the object InitScreenPixmap is created which executes the script. You can put in any valid Kommander actions into the script. So what did I put in my InitScreenScriptObject? I put in a directory creation command and a ping test. I have also set up some global variables in this InitScreenScriptObject as well.

The ping test is done in order to enable or disable choices in the following screens. Depending on the ping success or failure, certain options later in the Wizard will be enabled or disabled. There was one problem I had with the ping setup- a delay in the Wizard startup. For instance, if the ping test failed, it could take 10 seconds for the ping to complete, delaying the startup screen to appear. That was unacceptable. Even if I could get the InitScreen to show up, there was still a strange delay that gave an interface inconsistancy feel. What could I do?

Use of a TabWidget Layer and dcop commands.

My first thought was Layers. I would set up a TabWidget called IntroTab with 2 Tabs. One with a "Please Wait" message and the other with all the Intro Message stuff. The "Please Wait" would be Tab 1 and the Intro Message would be Tab2. I would start out the wizard on Tab1 and after the Ping was successful, switch to Tab2 via a dcop command.

That setup took care of one aspect of the interface, but I still had that uncomfortable startup delay AND the fact that the Tab1 message NEVER showed up since the ping was holding up everything from being drawn. The following was the code I used:

@execBegin(bash)
stat=`(ping -c 2 www.slax.org 1> /dev/null;stat1=$?;echo $stat1)`;
if [ ${stat} -ne 0 ]; then
dcop @dcopid KommanderIf setEnabled Driver_Retrieve_Button false
dcop @dcopid KommanderIf setVisible Label79 true
dcop @dcopid KommanderIf setCurrentItem IntroTab 1
dcop @dcopid KommanderIf setEnabled AdapterDriver_BG false
dcop @dcopid KommanderIf setEnabled AdapterDriver_BG2 false
dcop @dcopid KommanderIf setEnabled next true
else
dcop @dcopid KommanderIf setEnabled Driver_Retrieve_Button true
dcop @dcopid KommanderIf setText Driver_Retrieve_Button "Retrieve &Driver"
dcop @dcopid KommanderIf setVisible Label79 false
dcop @dcopid KommanderIf setCurrentItem IntroTab 1
dcop @dcopid KommanderIf setEnabled AdapterDriver_BG true
dcop @dcopid KommanderIf setEnabled AdapterDriver_BG2 true
dcop @dcopid KommanderIf setEnabled next true
fi
@execEnd

But it was NOT suitable, since the Wizard waited to come up until AFTER the ping had completed. Also the "Please Wait" message did not show up. Very strange behavior. So I tried the following to replace the @execBegin/End block:

@exec((stat=`(ping -c 2 www.slax.org 1> /dev/null;stat1=$?;echo $stat1)`; if [ ${stat} -ne 0 ]; then dcop @dcopid KommanderIf setEnabled Driver_Retrieve_Button false; dcop @dcopid KommanderIf setVisible Label79 true ; dcop @dcopid KommanderIf setCurrentItem IntroTab 1; dcop @dcopid KommanderIf setEnabled AdapterDriver_BG false ; dcop @dcopid KommanderIf setEnabled AdapterDriver_BG2 false ; dcop @dcopid KommanderIf setEnabled next true; else dcop @dcopid KommanderIf setEnabled Driver_Retrieve_Button true; dcop @dcopid KommanderIf setText Driver_Retrieve_Button "Retrieve &Driver"; dcop @dcopid KommanderIf setVisible Label79 false ; dcop @dcopid KommanderIf setCurrentItem IntroTab 1; dcop @dcopid KommanderIf setEnabled AdapterDriver_BG true; dcop @dcopid KommanderIf setEnabled AdapterDriver_BG2 true; dcop @dcopid KommanderIf setEnabled next true; fi))

Still the Wizard waited on the @exec to complete before the Wizard would come up. I needed to have all the used @exec commands to do their thing AND have the Wizard come up. How to fix it though. I decided that I would try putting the @exec command contents in the background- @exec ((commands)&). That did the trick!

To get the wizard to come up so that the "Please Wait" screen showed up while the ping test was being performed, this is what I ended up doing:

@exec((stat=`(ping -c 2 www.slax.org 1> /dev/null;stat1=$?;echo $stat1)`; if [ ${stat} -ne 0 ]; then dcop @dcopid KommanderIf setEnabled Driver_Retrieve_Button false; dcop @dcopid KommanderIf setVisible Label79 true ; dcop @dcopid KommanderIf setCurrentItem IntroTab 1; dcop @dcopid KommanderIf setEnabled AdapterDriver_BG false ; dcop @dcopid KommanderIf setEnabled AdapterDriver_BG2 false ; dcop @dcopid KommanderIf setEnabled next true; else dcop @dcopid KommanderIf setEnabled Driver_Retrieve_Button true; dcop @dcopid KommanderIf setText Driver_Retrieve_Button "Retrieve &Driver"; dcop @dcopid KommanderIf setVisible Label79 false ; dcop @dcopid KommanderIf setCurrentItem IntroTab 1; dcop @dcopid KommanderIf setEnabled AdapterDriver_BG true; dcop @dcopid KommanderIf setEnabled AdapterDriver_BG2 true; dcop @dcopid KommanderIf setEnabled next true; fi) &)

Note: the WHOLE if-then-else block is in ()'s so that it is ONE process and it is spawned off in the background with the use of an &.
Also Note the ping structure: stat=`(ping -c 2 www.slax.org 1> /dev/null;stat1=$?;echo $stat1)`
It seems a little strange but here is the deal.
Using ping -c 2 www.slax.org 1;stat=$?;echo $stat yielded a 141 exit code for ping. Why? I have no idea. On the bash command line it yielded the expected exit codes but not in the @exec(). So I used (ping -c 2 www.slax.org 1> /dev/null;stat1=$?;echo $stat1). Since that echo's a number, I set the result to stat. Then used that $stat for the if-then-else check.

After the ping was completed (successful or not), I set the TabWidget, IntroTab, via dcop to the second Tab to display the Intro Message.

This worked GREAT! But it created 1 additional problem. While the ping test was being performed, the Next button was active, just BEGGING to be pressed. So, I disabled it using a dcop command and then re-enabled it after the ping test, in both if-then-else clauses. I put the following before the above the @exec(ping/if-then-else clause):

@exec(dcop @dcopid KommanderIf setEnabled next false)

That takes care of Page 1 of NetWizard! If you are wondering about the other dcop commands that enable and make visible other widgets, they will be explained in later NetWizard forensic tutorials.

"Layers" in a Kommander Page - Part 2

2006-09-11T19:11:00.000-07:00

Disclaimer: I use Kommander's kmdr-editor and kmdr-executor 1.2 Using an older version that that WILL result in some example NOT working.

Last time we discussed how to simulate the concept of "Layers" in a Kommander Page. This article just discusses a same page technique for doing something similar. For instance, utilizing a Radio Button group, 2 or more Canvases can share the same page. In this example there will be "2" Radio Buttons that will toggle back and forth between two Tab Widget pages. The same technique used in the last article places the Tabs out of view so that the page looks to just change its contents when the Radio Buttons are toggled between the two choices. We stated "2" Radio Buttons, there are really 4- a group of 2 on each Tab Widget Page.

The setup is very easy. Just create a TabWidget (call it tw1). On the first TabWidget (tw1) Page create a 2 button Radio Button group- call them RB1_1 and RB1_2. On the second TabWidget (tw1) Page create another Radio Button group- call them RB2_1 and RB2_2. Ensure that the Button Group Boxes have the same geometry (same size and location) on their respective pages, otherwise flipping between the two pages will result in a visual discontinuity.

Next create 2 ScriptObjects- SC1 and SC2
In SC1, put in the Kommander Text Default box
@tw1.setCurrentItem(0)
@RB1_1.setChecked(1)
@RB1_2.setChecked(0)
@RB2_1.setChecked(0)
@RB2_2.setChecked(1)
In SC2, put in the Kommander Text Default box
@tw1.setCurrentItem(1)
@RB2_1.setChecked(0)
@RB2_2.setChecked(1)
@RB1_1.setChecked(1)
@RB1_2.setChecked(0)

If you are wondering why there are 4 lines in each ScriptObject, it is because the Widget Methods need to be set properly since the 2 Button Groups are NOT linked together. For instance, when you are on TabWidget (tw1) Page 1 and click the RB1_2, it is set to true and the Tab Page changes to Page 2. But the Radio Buttons on Page 1 need to be reset back so RB1_1 is true and RB1_2 is false, in preparation for the switch back to Page 1 when RB2_1 is pushed. The same reason holds for the other Button Group RB2_1 and RB2_2.

The last step is to set up Connections for 4 Signal/Slot actions:
RB1_1:toggled(bool):SC1:execute()
RB1_2:toggled(bool):SC2:execute()
RB2_1:toggled(bool):SC1:execute()
RB2_2:toggled(bool):SC2:execute()

NOTE: You may wonder why there is an RB1_1 and RB2_2 Signal/Slot connection. It is to cover the event that RB1_1 is clocked on the tw1's first page and RB2_2 is clicked on page 2. WIthout this Signal/Slots the Radio Button will fill in and clear out if clicked multiple times.

That's it!

"Layers" in a Kommander Page - Part 1

2006-09-08T13:51:00.000-07:00

Disclaimer: I use Kommander's kmdr-editor and kmdr-executor 1.2 Using an older version that that WILL result in some example NOT working.

There are times when you wish to have a choice (say Radio Buttons) in your wizard, present different pages of options. For instance, on page 1, there are 3 radio buttons (RB1, RB2, RB3), each of which have 3 different pages of choices BUT those choices need to be presented on the NEXT page. Some thoughts to making the Next Button jump to a specific Wizard page depending on your Radio Button choice is a possibility. The problem with that approach is that you need to keep track of options and what current page you are on in the event the user selects the Back button.

The simple option to deal with this problem is to use a Tabbed Widget. Just make the Tabbed Widget (say TabWidget1), bigger than the Wizards viewable canvas size before deployment. In our example, there are 3 Radio Buttons and 3 separate choices of options per button. Just make a 3 tab Tabbed Widget on the Next Page, put all your options on the appropriate Tab page, and then place the Tabs off the viewable canvas so the user can't see them.

Working Example:
On Page 1, Create your 3 Radio Buttons: RB1, RB2, RB3 and Group them in a Button Box.

Create 3 script objects: ScriptObject1, ScriptObject2, ScriptObject3 and put the appropriate command in each one-
In ScriptObject1 put: @TabWidget1.setCurrentItem(0)
In ScriptObject2 put: @TabWidget1.setCurrentItem(1)
In ScriptObject3 put: @TabWidget1.setCurrentItem(2)

Now use signal/slots to connect the buttons to the scripts:
RB1:toggled(bool):ScriptObject1:execute()
RB2:toggled(bool):ScriptObject2:execute()
RB3:toggled(bool):ScriptObject3:execute()

On the Next Page, you will set up your 3 Tab Tabbed Widget and place all the appropriate contents in each of the respective Tabs. Name the TabWidget the name you used in the ScriptObjects- in this example, TabWidget1

Resize the Wizard's Canvas size and position the TabWidget on the Page so that the Tab section and the Tab box boundries are out of view.

That's it! Simply, all this is doing is selecting a specific Tab when a Radio Button is selected, but the "effect" seen by the user, since they can't see the Widget Tabs, is that the Next page "changes" depending on what options they choose.

Hope that technique helps with your Wizard Projects!

Kommander Projects

2006-09-08T13:50:00.000-07:00

Current Kommander Projects:

1) NetWizard/QuickNetWizard
First release Features:
http://www.speedyshare.com/177831228.html

1) Easy to use Wizard for configuring SLAX network interfaces.
2) NDISWrapper driver configuration for: DHCP and Static configurations.
3) Front-end produces output file of options chosen within the Wizard.
4) Back-end program will use config file or parameters to setup network adapters and make a SLAX module of the configuration.
5) Back-end program can be used by any frontend.

Future Features:

1) Database of known working configurations to allow "auto" config. This location of known drivers will be in the DB.
2) "Database" tool to allow adding to the configuration knowledgebase. Many contributors makes for rapid grown and for easier auto config for the populace at large.
3) Auto driver download from known sites hosting drives. This is just an automated extension of #1's location information.
4) Kernel driver configuration for: DHCP and Static configurations. Both existing supported drivers and newly compiled drivers will be supported.

2) MySLAXKreator
MySLAXKreator is pretty much is just a clone to MySLAXCreator but one of the differences may be the addition of package fetching through a network connection maybe using the same mechanism as Kommando-Installer.

It will use Kommander as the GUI FrontEnd; make_disk.sh for USB and disk installation; and make_iso.sh and cdrecord as the backend processing tools.

3) Kommando-Installer
There is a real need to make software available without actually "distributing" the software. Two types of software that fit this category are: proprietary and encryption. Both are essential parts of the Linux experience but they have issues with distribution for everyone involved. To cover everyone's tail, I have decided to create an installer that will download all the pieces, create the software, and make a SLAX module. The end user needs to do nothing but select a piece of software and single click.

Proprietary video drivers, for instance, can be downloaded, compiled for your Kernel release, and a module created with NO technical knowledge of any kind.

A cool side effect of Kommando-Installer is that this can be used to distribute modules. Just update the master software package list, create a profile with the URL, the installation instructions can be to install it into the modules directory, and that's it!

Kommander Widget Method Reference

2006-08-27T14:59:00.000-07:00

From a mailing list message from Eric Laffoon Project Lead - kdewebdev module

http://mail.kdewebdev.org/pipermail/kommander/2004-July/000129.html

Widget: ButtonGroup
* setChecked
* text
Widget: CheckBox
* setChecked
* setText
* text
Widget: CloseButton
* setText
* text
Widget: ComboBox
* clear
* currentItem
* insertItem
* insertItems
* item
* removeItem
* selection
* setSelection
* setText
* text
Widget: Dialog
* setText
* text
Widget: ExecButton
* setText
* text
Widget: FileSelector
* clear
* selection
* setSelection
* setText
* text
Widget: GroupBox
* setText
* text
Widget: LineEdit
* clear
* selection
* setSelection
* setText
* text
Widget: ListBox
* addUniqueItem
* clear
* currentItem
* findItem
* insertItem
* insertItems
* item
* removeItem
* selection
* setCurrentItem
* setSelection
* setText
* text
Widget: RadioButton
* setChecked
* setText
* text
Widget: RichTextEditor
* clear
* selection
* setText
* text
Widget: SpinBoxInt
* setText
* text
Widget: SubDialog
* text
Widget: TabWidget
* setText
* text
Widget: TextEdit
* clear
* selection
* setText
* text
Widget: TreeWidget
* clear
* currentItem
* findItem
* insertItem
* insertItems
* item
* itemDepth
* itemPath
* removeItem
* selection
* setCurrentItem
* setSelection
* setText
* text

KDE Kommander

2006-08-25T16:20:00.000-07:00

One thing that Linux has lacked is a Wizard Building facility that is easy to use as well as self-contained. There are few tools out there that can create Wizard-like interfaces without having to manually insert code to make the end product work. One aspect that haunts Linux (IMHO) is the lack of nice GUI configuration tools. Sure, Im a hard core Linux CLI advocate, but, for the public at large... type this, type that, just doesnt cut it. I like a GUI that produces an output file that you run through a filter script. That way the front end GUI can be use with many backend scripts. I see the GUI as a way to collect information. Then it is up to the filter to gleen any specific information needed and run whatever scripts are needed to process that information. All of this can be called from within the GUI framework so no wrappers should be needed but it can be up to you to do that if you want. What I dont like are GUI configuration tools that at least somewhere (in the man page even), there must be reference to what files are created modified, etc.

With the advent of personal Linux distros such as SLAX (slax.org) many variants are being born and created for specific things- Backup/Restore, Disk Repair, SOHO tools, Video Editing, Music Creation, etc. With each of those distros, there comes a need for custom configuration tools. So obviously, there is a great need for a Configuration Tool Builder.

Enter Kommander from the KDE project (www.kde.org)

I think Kommander has a lot of potential... To learn more about this project you can visting their home page at kommander.kdewebdev.org/ But there are some areas of improvement...

1) Need updated and better documentation.
2) Constant changing of the Widget names... this can be ok IF the documentation is up to date AND there is backward compatiblity mode that dumps out a log file, or a utility that scans the kmdr file and warns of deprecated feature and widget names.
3) The project is in desperate need of a Wiki for documentation, examples, etc.
4) The mailing list format is rather old school esp since there is no archive search features. Thank goodness for deja/usenet. The groups there are somewhat helpful. A Forum format would be very nice.

All that aside, I am very impressed with the project and Kommander capability. It is quite a nice self contained Dialog and Wizard builder. But it also allows external script usage which allows it to really leverage off of the powerful abilities of Bash, Perl, Python, etc.

The interface is quite functional and is easy to navigate around in. The icon bar can be a little confusing since different functions have the same icon (LineEdit and FileSelector for instance.) The newer interfaces are MUCH better than previous incarnations, and it seems each generation gets nicer and better. I STRONGLY recommend visting sourceforge.org and kde.org to obtain the latest kommander tools and kdewebdev development source before starting your development. This will ensure that you have the latest and won't be using old, out-dated, deprecated software.

Kommander (you may wish to get a particular version of Kommander from here)
sourceforge.net/project/showfiles.php?group_id=62795

kdewebdev (Kommander is included in this package)
prdownloads.sourceforge.net/quanta/kdewebdev-3.5.3.tar.bz2?download

Kommander Documentation...
docs.kde.org/stable/en/kdewebdev/kommander/
I am using Kommander to create some custom Wizards for various things. An S/MIME certificate creator, a Network configuration Tool for use with SLAX and a clone of MySLAXCreator called MySLAXKreator. Checkout slaxworkshop.blogspot.org