[Kommander-devel] I hate Kommander

[Dik Takken]

>> You're cracking me up. Kommander is a paradox that you should learn
>> to see.
>> 1) It is "different thinking" than an experienced developer.
>> 2) Ironically it is easier for non developers to pick up.
>> 3) You are an extremely accomplished C++ developer.
>
>So it is better if I remain at C++? ;-)

> Take
> this example:
> a="first second third"
> for i in $a
> do
>   @List.insertItem($i, -1)
> done
>
> This does not work with the current Kommander, because @List.insertItem
> is evaluated before the for loop even starts.

Personally, I try not to mix Kommander code and Bash, because:

* I keep making mistakes, there is no syntax highlighting
* Evaluation order is confusing and causes even more bugs
* The code editor in Kommander is too basic for coding in general
* Code is hard to debug when running inside Kommander

Looking at the above code, I would have split the code in a pure 
Kommander part and a pure Bash part, like so:

  @List.insertItem(@GenerateItems, -1)

Where @GenerateItems is a seperate, pure Bash script object:

  a="first second third"
  for i in $a
  do
   echo $i
  done

For a simple script like this, I would create the bash script object 
within Kommander. For more advanced scripts, I would create an external 
file using a good editor like Kate. Creating external scripts also gives 
me free choice of scripting language. Bash, PHP, Perl, anything that can 
output strings will do.

I think we could make Kommander a lot easier by changing the programming 
style from 'Mixed' to 'Pure' scripting, like shown above.

In order to overcome the problems discussed in this thread, I would like 
to suggest the following:

* Introduce various kinds of 'pure' single-language script objects into 
commander, like a Kommander script object, a PHP script object or a Bash 
script object. Each script object can only contain one script language: No 
mixing allowed.

* Any script object can receive arguments, which can be referred to from 
inside the Kommander/Bash/PHP/etc script. Kommander will replace these 
references with the actual arguments before running it.

* Each script object can be called from any other script object

* The Kommander Text will be a reference to one of the script objects that 
are defined in the dialog. There will be no more 'static' scripts in a 
Kommander dialog, only references to script objects.

The advantages are:

* No more confusing mixtures of scripting languages
* Replacing Kommander Texts with a reference to a script object reduces 
code duplication: Multiple widgets can share one 'Kommander Text' which 
can be edited in one place.
* We can support many scripting languages with little effort
* Because we know the scripting language for each object, we can use 
Kate KParts for editing the scripting objects and set the correct 
syntax highlighting scheme. Integrating complex scripts into Kommander 
will become doable.
* In theory, we could even support simple C++ 'script' objects that can be 
compiled when the dialog is loaded.

In short: You can avoid the confusion of mixing scripting languages by 
using a different coding style. This coding style can be implemented into 
Kommander itself, so every Kommander user will automatically develop 
Kommander dialogs that are much easier to understand and maintain.

Cheers!

Dik