[Kommander-devel] I hate Kommander

[Eric Laffoon]

Wow, a real positive post from Andras. ;-)

On Monday 19 September 2005 7:34 am, Andras Mantia wrote:
> <rant>
>  I hate Kommander. I tried to create a small utility to download images
> from my digital camera and I spent several hours on it without success.

So send me a copy and let me look at it.

> I tried to do the "bash" way, but Kommander imposed lots of problems
> with the issue that Kommander specials are run first, and bash has its
> limitations as well. 

Marc basically wrote it to be language neutral but made it bash specific. Bash 
is confusing (maybe not to you), slow and inconsistent.

> The biggest problem was that without an 
> echo ""
> at the end of the button text, the other button did not work correctly.
> The code in the first button inserted some items in a list, the second
> gathered the selected items from it. Without the empty echo, you did
> not get back any selected item and nothing was run from the code of the
> second button. Go figure.
> Oh, and echo is not working in the dialog initialization code.

You have several options including...
@exec(echo "something")
@debug(some info)
@Message.info(test message, test)

You can also switch to the new language mode.
>
> I tried with the Kommander way, using @ functions wherever is possible.
> The beginning was promising. The end was a disaster. I could not figure
> out how to set a local variable and how to use it. So I had to use
> globals.

Local variables are not available when using @ functions. They are only 
available with the new parser and you have to set that mode. Unfortunately 
there are some bugs with that and Michal and I have to address that.

> I could not figure out how to test if a string contains a substring or
> not.
Did you look at this?
kdewebdev/kommander/examples/tutorial/strings.kmdr
When using the string functions, which are in a separate group in the function 
broswer BTW, you need to use quotes to make sure nothing gets confused.

> I get interesting errors in the following code: 
> @setGlobal(selection, at FilesList.selection)
> @debug(@global(selection))
> @forEach(i, @global(files))
>
>  @if (@contains(@global(selection), @i)!="")
>     @debug(@i)
>  @endif
> @endfor
>
> "Error in widget DownloadButton:
> Unknown special: 'endfor'."

There is no @endfor, only @end. Actually somebody submitted a patch for @else, 
@elseif but Michal rejected it for the new parser which allows unlimited 
nesting. Personally I'm thinking we need to resolve things and possibly patch 
that simply to avoid confusion, but in any case you cannot nest @ more than 
@if in a @case or @for.
>
> whatever. The documentation lacks a lot of things. The function browser
> is promising, but has problems (like saying you need @endif for the
> forEach), starts always from the same widget, and DCOP calls, needing
> lots of clicks here and there.

I'm open to input and patches. This is one reason I want to improve my C++ 
coding. I also need to release the database plugin and do fund raising to 
catch Michal up but I have not heard from him since aKademy. 

> The lack of good error reporting, lack of autocompletion and a decent
> editor makes things even worse.

There is some error reporting now. It could use improvement but it's not too 
bad. I discussed with you at aKademy how I want to change the layout to the 
editor being the main window. In fact my idea to use Quanta is all the more 
rational now that Quanta will be using KDevelop... We need project tools, an 
editor, highlighting, auto completion... All of these things are available in 
customizable software. The GUI design needs to be on top of the editing 
environment instead of how it is now.

I've also asked in the past if you might help us with the editor.

> But the thing I most hate is that you cannot really use the Kommander
> specials together with wathever scripting language you want. And this
> defeats the whole idea behind Kommander. Sooner or later you are forced
> to use the Kommander language, which lacks documentation and many
> items. When you mix two languages it is hard to figure out what will
> happen.

There is an easy solution for this and the new parser is particularly good 
here.
Structural logic flow -> Kommander script
Program operations -> Language of choice in Action scripts

In particular we need to modify Kommander as follows:
1) Move from scripts to Actions and enable Mainwindow operation with menus and 
toolbars.
2) Enable passing parameters in signals/slots and look at how they can be 
integrated into the Action model.
3) Have an Action panel instead of script widgets.
The idea is that if you want to run a script you either encapsulate it in an 
exec() call like other languages or you call an action script.

The difficult way is to create DCOP libraries for different languages, but 
this would be cool to work with for languages that have them because then you 
could work from start to finish with that language for logic and operations.

> Well, now I give up. I wanted to ease my job of typing two commands in
> the command line, and made my life harder to fight with Kommander.
> </rant>
>
> And what to do?
> 1) improve the editor with autocompletion, context help, descriptions of
> the methods and how you can do things, code examples in the
> documentation.
> 2) get rid of the madness about @execBegin, @exec, whatever. It is so
> inconsistent, I never know when to use which and sometimes I stand
> there and stare why things do not work
> 3) make Kommander intelligent to work together with script languages.
> yes it is hard, requires a rethink and rewrite of the tool, but it is
> something that is needed, otherwise we  just invented the N+1-th
> scripting language.
>
> Sorry, but I'm not in a good mood (for other reasons as well, and
> because of this)
>
> Andras
I have other reasons to not be in a good mood as well. Let's fix this one. ;-)
-- 
Eric Laffoon
Project Lead - kdewebdev module