[Kommander-devel] I hate Kommander
Andras Mantia
amantia at kdewebdev.org
Tue Sep 20 13:26:30 EDT 2005
Hi Eric,
Ok, I'm trying to be calm today. ;-) Anyway, the weather can easily
cool me down as it is 11C outside and less than 20 inside. It seems we
have to make fire in the stove.
On Monday 19 September 2005 23:33, Eric Laffoon wrote:
> 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++? ;-)
> Kommander. The operational term is learning the particulars. Once you
> understand them in Kommander it is assuredly faster because you don't
> have to do anything but logic and operations.
That would be the ideal way. My opninion about Kommander is that it
should not stay in you way. It should be no more than a tool which
provides you widgets and ways to modify/access those widgets and gives
some structures to the code, by making it possible to associate code
with widget actions. It should allow me to write whatever I want in the
language I choose, be it bash, perl, ruby or what. I choose bash, as I
don't know the others and most people at least understand it somewhat.
The main problem that arised was that Kommander specials are evaluated
before the code is passed to the script interpreter. This is what
causes the madness about not being able to pass variables between your
script language and Kommander. Some time back I already proposed a
solution, but it was ignored. It was about not doing in this way. 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. Instead of this right now
you have to use something like:
a="first second third"
for i in $a
do
dcop @dcopid KommanderIf insertItem List $i -1
done
It is ugly (but maybe @dcop works as well), but the problem is that it
is slower. I agree, but Kommander is not for time critical
applications, so this kind of slowness should be acceptable, especially
if there is another way to do it (the "Kommander" way).
My suggestion was that for every language Kommander supports we provide
the code that will be put instead of @List.insertItem or whatever. So
the user still works the first version, and as Kommander knows this is
bash, it will replace
@List.insertItem($i, -1)
with
dcop DCOP-ID-OF-THE-EXECUTABLE KommanderIf insertItem List $i -1
Same for other Kommander specials, like @Message.
In some languages there might be direct DCOP bindings, so you will not
have to use the "dcop" command line tool to communicate with Kommander
and will be much faster.
The ways to access DCOP methods in a language will be described in
external files, like in case of Quanta's DTEPs. Two methods should be
offered for each language:
- a way to call DCOP methods directly (if there is such way)
- a way to execute external applications. This will be used to launch
the command-line DCOP tool if the first methods is not available
Clear, simple and will just work in a way the coder expects.
This way you can explore your language's full possibilities without
problems and still communicate with Kommander.
Now, if you want to go the Kommander way and use @for, @if, @String and
whatever, you declare at first that this is a Kommander script, and
than you don't write code in other scripts, except inside @exec or
maybe between @execBegin and @execEnd. Still in this case a fundamental
problem must be solved: to pass variables between the Kommander part
and the other script part, most probably with the above solution. How?
For example:
#!Kommander area
... some code with Kommander specials
@execBegin(#!/bin/sh)
... some bash code
@execEnd
... some other Kommander code
This could be replaces by:
dcop @dcopId KommanderIf execute Areaname
... that some bash code
dcop @dcopId KommanderIf execute Area2name
So to the Kommander areas names are assigned (automatically) and the
DCOP method executes them. It may be that the execution is not a simple
DCOP method, but something like
kommandervars=`dcop @dcopId KommanderIf execute Areaname`
so you get back all the Kommander variables in an array.
Or if this sounds too complicated, remain at the current solution, that
the Kommander part starts to run, and when at exec you execute that
part in the interpreter. Still, whenever in that part there is a
reference to a Kommander special, replace it by a dcop call.
So
bashvariable=@KommanderVariable
would become
bashvariable=`dcop @dcopid KommanderIf getVariable KommanderVariable`
Same in the other way
@KommanderVar=$bashvar
is replaced by
dcop @dcopid KommanderIf setVariable KommanderVar
just before execution.
Bigger problem is to access the bash variables *after* execEnd. Two
solutions:
- don't do anything, require to save the variables in the bash part to
Kommander variables
- automatically save them in @execEnd using some predefined names like
appending "_bash" or "_perl" suffixes.
> Houston we have a problem... My Samsung Digimax 301 is not on the
> list for gphoto2 and is not recognized even when I provide the device
> with --path=. My camera is however USB mass storage so fortunately I
> don't need gphoto2.
Don't worry, I can give you an example without gphoto2. Just replace the
files=`gphoto2 ...`
line with
files=`ls -1`
If the echo is at the end, the echo in the Delete script works,
otherwise it doesn't. They are completely independent scripts!
> > - press "Delete". It should list the selected items. Problems:
> > 1) echo "selection=$selection" : does not work
> > 2) @exec(echo "selection=$selection") : does not work
> > 3) @debug($selection) : outputs "$selection"
> > 4) @Message.info($selection, selection): outputs "$selection"
> > Conclusion: there is no way to print out the $selection
> > variable.
>
> There's a lot of problems with this because you're still mixing bash.
What is the problem here? I was told that by default the scripts are run
in bash. Thus 1) should work. 2) should work even more. I simply
execute an external command. It is not about "echo". @exec(ls) doesn't
work either. Even more funny:
selection=`dcop @dcopid KommanderIf selection FilesList`
echo "selection=$selection"
@exec(ls)
@debug($selection)
@Message.info($selection, selection)
Do you know what happens if I execute this code? "Kuanta/KDevQuanta" is
executed!!! Now should I laugh or cry? ;-) There is no sign of
"kuanta" (the name of the executable) there....
> It would be better to switch on Kommander script.
I don't want to. I want to do in my own script language! This is the
point.
> > - now add an
> > echo ""
> > line at the end of the Fetch kommander text. Surprise, suddenly the
> > 1) works! 2) still doesn't work, 3) and 4) prints again literraly
> > "$selection".
> > And this is not only about echo, as basicly no bash code works in
> > this part.
>
> Well first of all I'm not sure exactly what you're expecting.
I would expect that all for items above prints out the selected items
from the FilesList. Oh, first, I would expect that the code I write is
executed at all...
> Each
> Kommander Text is local so in order to work between them you need
> either a Kommander global or use environment variables with bash,
> which Kommander supports with @env IIRC.
Using globals are ugly, but I accept that locals are not available.
Using enivornment variables is a good idea, I did not think about them.
But I think my solution at the beginning is much better.
> > Also notice that the "Starting up" texts from the dialog's
> > initialization code do not work. Only the @debug works there!
>
> First of all there may be some problem with echo, but I need to
> verify...
As I said, it is not about echo itself. An echo is BTW a basic
operation. If it doesn't work, there are big problems.
> I see what you're saying. You would have to ask Michal to
> really clear this up but I'll try. First is a bash call without a
> shebang in a regular widget. IIRC we don't support this in non button
> or script widgets.
Why? This is inconsistent! Either require the sheebang or execBegin
everywhere, or don't require it anywhere.
> For a while Michal had made it so that the buffer
> was not flushed until closing.
That's not the problem, as I said a completely unrelated echo "" fixes
the bug.
> I'm not sure about no echo. I believe
> echo works in Kommander script. Anyway this is really a debug type
> message. I know I can send text from a button to stdout. I added this
> line to the close button and it works...
Sure, it works some time. But not always. And printing debug information
is not always possible with @debug, as it does not know about the shell
variables.
> Actually it's pretty much the same as the others. All it really
> offers is a slightly different notation for widgets with the same
> functions, which is handled by the function browser, and the addition
> of if/elseif/else/endif along with local variables.
Still, it is a new language, and not something that extends any other
language, which was the idea behind Kommander.
> basic operations. Complex programming tasks would be what you would
> write in scripts with other languages, but ironically about 80% of
> programming isn't that complex.
Look, what I have to do here is:
- I have a list of entries in a form of
1 filename
2 filename
3 filename
- put the filenames in a list, and when you delete/download them, get
back the number associated with the selected filenames.
I don't find it complex. Bash has it's limitations to handle arrays, but
Kommander has it's limitations to cooperate with bash when needed, and
this caused my headache.
> > No, but why isn't the Function browser enough? Oh, well, it doesn't
> > even tell me the possible return values.
>
> Is this really Andras? You obviously missed it in the function
> browser... unless someone took it out.
String.contains:
Description: Checks if the the string contains the given substring.
Syntax: contains(QString string, QString substring)
But what does it return?
String.isEmpty, isNumber is the same. I see that others have it, but
these are not, and it's enough if I just wanted to use one of these.
ListBox.selection
Description: Returns selected text or text of current item.
Syntax: selection
And what does it return if multiple items are selected?
I'm sure I could find others as well.
> I believe it is in the docs which regrettably are probably only on
> site, but they are there. We really need to get an effort going to
> fix all this for KDE 4.
It is not mentioned in the "String Function Group" of the handbook.
> > Wrong.
> > @forEach(i, @global(files))
> > @debug(@i)
> > @endfor
> >
> > Just works.
>
> Really? Where's Michal?
Who knows? ;-)
> > But
> >
> > @forEach(i, @global(files))
> > @debug(@i)
> > @# @if (@String.contains("@global(selection)", "@i")!="")
> > @# @debug(@i)
> > @# @endif
> > @endfor
> >
> > does not, and does not work even with @end instead of @endfor. See
> > the commented out lines?
> > Not talking about the fact that the function browser says one shoud
> > use "@endif" for @foreach...
>
> Somebody should fix this, but I thought I worked on that at 3 am the
> day before a string freeze. I can't believe this.
Yeah, the documentation is easy to fix (and it qualifies for a bugfix,
so I will do it, once I learn which is the correct way to close @if,
@for and @forEach), but still, why doesn't the above work?
> This would work by using a variable pool in Kommander and passing
> parameters. Besides, if a program is fairly modular you don't need to
> deal with more than a little integration of data.
I told you about my little problem to solve. I don't need more than 2
arrays and a little logic.
> The language interaction question is pretty fundamental. You have two
> programs separately executing and you need to synchronize between the
> two at particular points to exchange data. This is just ugly.
Yes, so you should make it one program, instead of two separate ones.
> Attached is a dialog to try.
This is not what I want and this one I could do it quite easily before
as well. This is just widget manipulating without real content in the
back.
Andras
--
Quanta Plus developer - http://quanta.kdewebdev.org
K Desktop Environment - http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://momo.creolmail.org/pipermail/kommander-devel/attachments/20050920/98e01113/attachment.pgp
More information about the Kommander-devel
mailing list