[Kommander-devel] I hate Kommander

[Andras Mantia]

On Thursday 22 September 2005 05:16, Eric Laffoon wrote:
> On Tuesday 20 September 2005 2:26 am, Andras Mantia wrote:
> > It should allow me to write whatever I want in the
> > language I choose, be it bash, perl, ruby or what.
>
> Unfortunately this has proven not to be completely realistic. If
> you're willing to accept certain limitations or do this in a more
> difficult way then yes.

My proposal addresses this just fine.

> bash is certainly common, but I don't think most people understand it
> a little, unless you mean very little. Our previous favoring of bash
> from Marc's work had some key differences. For one it was not nearly
> as powerful as Kommander is now, so it really cannot be compared.
> Another factor for us is how many support requests we might expect to
> get from people trying to do things. Unfortunately in this regard
> bash is the most likely to create problems and the least likely to be
> easy to integrate. Finally there is the rather serious issue that you
> can watch the widgets draw if you have even just a few calls because
> it's so terribly slow.

Again: it's not about bash. Bash is just one, I could name any other 
instead.

> recognizing the inherent challenge. Suppose I want to use Rexx? With
> your analogy I need to write a DCOP library for Rexx or shell out to
> bash which is hundreds of times slower. 
No! You use the equivalent to "exec(dcop your_dcop_command)" in Rexx! Or 
use the second (Kommander) approach, if you want, but you will still be 
able to just use Rexx.

> Yeah, here's the thing...
> 1) It's not just slow, it's hideously slow. I mean watch the widgets
> draw and set when used with start up scripts.

It is slow only for lists. Luckily there are dcop commands (and can be 
added) to deal internally with bunch of data. And this kind of slowness 
is not a critical factor in Kommander applications.

> 2) What you have there can generally be done in one line as opposed
> to the 5 lines you have and the operation there is much faster too.
I don't see how will be smaller the amount of code (see my example with 
those global and other strangeness). A for loop will still remain a for 
loop.

> This is particularly noticable when filling a tree or listbox with
> hundreds of items where there are orders of magnitude difference in
> speed.
Use the dcop command with a list as argument!

> 3) While we're on the subject, bash is ugly, inconsistent and an
> invitation to get questions how to do things.
Again: it is not about bash.

> 4) By providing a point and click interface for something that only
> takes a line or two of code the only person who is going to have a
> problem with it is a professional coder who doesn't have to look at
> docs for every line and wants to just type what he knows.

No, point and click with little code is an utopia. Sooner than later you 
will have to write code that has some logic.

> 5) The most logical way to support common languages is to use a
> common framework for execution logic and then plug in operation
> scripts in various languages. Say we have python, perl and ruby
> programmers working together and some perl work needs to be upgraded
> by the python coder. If it's just a small script he could rewrite it,
> but if it's the whole dialog the benefits of modularity are lost.

I don't see how this scenario can happen if we implement my proposal.

> I would remind you that the speed difference is around 100 times
> faster for internal calls. In my installer application setting four
> checkboxes with external DCOP caused obvious flicker as you saw them
> set. They come up clean with internal DCOP. 
Than use internal DCOP. But leave the possibility to use external one in 
a clean way.

> Mainwindow use. But in fact the old external DCOP is still supported.
Partly yes, but the mixing of different styles is just madness.

> > 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.
>
> That's hideous!
You mean bad?

> For a second I thought you had a flash of genius. 
> What about converting the other language calls to Kommander calls
> with a pre-processor?
You cannot do that. You will need a parser for each supported language. 
But you can do the other way around.

> Doing what you're suggesting with bash is a 
> recipe for disaster when we enable Mainwindow with menus and actions.
> A small application would be a total dog and people would be sending
> us bash questions because for whatever reason that's the language
> they had to maintain or somebody steered them there. For the record
> bash is hideous. It's useful for some things but could easily be
> replaced by perl or python today.

Again: it is not about bash.

> This is certainly something I'd like to support. Who's going to do
> it? My thinking is that if we can get the other things I want done we
> will find people wanting to work on this.
I think this is more important.

> I think many languages 
> already have DCOP bindings. This is a good example of a tool that
> creates external DCOP.
> http://kde-apps.org/content/show.php?content=13125
> Note it's made with Kommander.
I would be happy if you could make my dialog to work correctly with 
Kommander, not using the Kommander language. ;-) You can do in PHP if 
you want, I don't care.

> What needs to be done is the fundamental improvements to Kommander...
> 1) Mainwindow and Wizard fixed
> 2) Actions instead of scripts
> 3) Parameters for signals/slots
> 4) New editor with highlighting and auto completion
> 5) Project tools/common install and run patterns and tools
> 6) plugin and tools framework
> 7) Better docs and enhanced site support including KStuff and XML
> pages hosting projects
Sure, but this will not solve the basics. I don't argue that Kommander 
can and should be extended. I may even accept that it's new language is 
good and useful, yet I still want to be able to write Kommander 
applications in the language I choose. This is the point.

> I don't think that will work like you think because eventually you
> want to pass a Kommander value to a bash variable in a loop. 
The bash loop is clearly separated and before entering, the Kommander 
variable is saved to a  bash variable (by the tool), the @var inside 
the bash variable is replaced by the autogenerated bash variable and in 
the end the Kommander variable is replaced by the bash variable.
Example:
@var="1 2 3 4 5"
@execBegin("#!/bin/sh)
for i in @var
do
 echo $i
done
@var="emtpy"
@execEnd
@debug(@var)

What I would expect as a result is:
1
2
3
4
5
empty (in stderr)

In order to make the work, Kommander would have to do the following 
before passing the area between @execBegin and @execEnd to bash:
var_bash="1 2 3 4 5" //takes the value from the @var. Kommander knows 
this value!
for i in $var_bash
do
 echo $i
done
setenv var_bash="empty"
@var=@env("var_bash")

All it has to know is how to set and get a variable from the script 
language. This can be also described in external files.
See what  I mean? Do you realize how easy will be to use your favourite 
language with Kommander this way? No need for tricks and headaches as 
the tool does the jon instead of you.

> The 
> bottom line is that it's just going to be too unreliable when you do
> this. Besides that's really ugly. If you can write
> if/elseif/then/endif and call Actions and easily navigate that it's
> better.
I'm sure that I (you/anyone) will soon find a missing command in 
Kommander's language and would need to mix with something else.

> You missed a lot of what we went through. Aside from bash being ugly
> and slow, did I mention bash is ugly and slow,

Again: it is not about bash.

> we encountered 
> problems in logic and particularly loops that could not be adequately
> managed. I don't recall the particulars and it's 3 am now... In any
> event...

I recall, and the problems are solved with my proposal.

> 1) Users are going to need to use DCOP calls or functions to access
> widget values so this is a given in any language.
Right. If the language does not support DCOP directly, execute the dcop 
command line tool.

> 2) Structural flow with Kommander is little more than @if/@endif,
> @switch/@case/@end and @for/@endfor. The new script language simply
> adds else, elseif and nesting while not including the switch
> statement. That's not difficult to do with a function browser and
> some people may even be able to memorize this given enough time. ;-)

But if I know another language and master it perfectly, why can't I use 
that one?

> 3) The new script language is very fast and can manage local
> variables.

But I doubt that it will be soon as powerful and useful as others 
already on the market. Yet, if somebody want to have it and learn it I 
do not oppose.

> The only thing missing is passing parameters with signals/slots and
> possibly with calls to Actions/Scripts.

I could name a few other as well:
- simple arrays
- multi-dimension arrays
- hard string manipulation
- missing integer and floating point manipulation (unless I miss 
something)
- lack of debugger
- lack of exact error reporting

>
> > 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
>
> This still sucks! I wish you'd take my word for it.

I cannot, as I don't believe it sucks. 

> Let's say that in 
> the above line your @KommanderVariable is set after the scipt
> initiated and was not certifiably static. That means that when the KT
> is interpreted it will parse all the @ values and then proceed to
> parse the bash. The problem is that if you set @KommanderVariable
> above with bash and then run the script you will set $bashvariable to
> an uninitialized or incorrect value. This is too easy to do and it
> means we will answer a lot of emails.
Sure, it does right now, but will not do this way if you follow me.

> The fundamental problem is that you have two asynchronous executions
> going on and you have to make sure there is no precedence issues.
No, you don't make it asynchrnous. That will be just madness. You give a 
flow to your code. 

> While you can make DCOP calls from bash it's not really DCOP enabled.
> Andras I'm really agonizing here. I need to find out where Michal is
> and get the database plugin released. As for what you're suggesting
> I'll make it simple. NO! 
Ok, my answer is: I refuse the *write* kommander scripts this way. I 
don't refuse to help on Kommander if you request (for example on the 
UI), but I certainly don't 
agree with the current way of working. There is nothing against what I 
said, really, aside of it has to be implemented. And maybe I will do it 
and prove it that I'm right.

I stop repsoding to the rest as it is pointeless. We don't agree and 
that's all. Case closed from my side.

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/20050922/a562ea83/attachment-0001.pgp