[Kommander-devel] I hate Kommander

[Eric Laffoon]

On Monday 19 September 2005 12:03 pm, Andras Mantia wrote:
> On Monday 19 September 2005 20:01, Eric Laffoon wrote:
> > Wow, a real positive post from Andras. ;-)
>
> Yeah, and before I comment the mail let me state one thing: the main
> problem I have is that a simple application requires so much trouble
> from an experienced developer, how hard can be for a beginner? I know
> bash somehow, I know the Kommander language idea and how was it
> designed (in general), still I fight with it without getting to an end.
> Well, maybe I gave up too early, but with the time I spent on it I could
> write the code in C++ as well.

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.

Given the above you probably could develop a number of small applications in 
C++ faster than you could _learn_ and do it in 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. I've released applications with less than 100 lines of code and 
we have non developers writing things like Katiuska.

Have said that I pretty much agree with you about documentation and 
improvements.
>
> > 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 will attach here the problem variants.
>
> > > 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.
>
> It's not about bash here. It's about interacting with a shell. It
> wouldn't help me if I'd used perl or php aside of the fact that some
> operations would be easier in that language, but not the interaction
> with the dialog.

Okay...
>
> > > 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)
>
> Yes and what if noone works just because in some other part of the
> widget there is something wrong. See the example1.kmdr. You must have
> gphoto2 installed and try "gphoto2 -L" with your camera attached to see
> if it produces the list of files on the camera. If this is OK, proceed:

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.

>  - press "Fetch". It fills up the list
I'll have to take your word for it. ;-)

>  - 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. It would 
be better to switch on Kommander script. I made it do a delete with a single 
line of code. As a C++ programmer you should appreciate replacing 4 lines 
that don't work. ;-) However my delete is for a single file. I'm pretty sure 
you can get a multiple selection and loop through it.

> - 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. 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. However there is still invariably issues of precedence in 
operations, but before digging into that it's just easier to use the 
facilities for this. That's not to say there aren't bugs, and if you want to 
look at it closer we can check, but as you can see, trying to mix procedural 
bash in can cause unpredictable results. You really need to choose one and 
hopefully Kommander functions or Kommander script is easier. Again, when this 
gets weird, create a script object and call it. This is a better way to 
containerize things and also creates a call to another KT element which 
sometimes helps with precedences, as well as being neater.
>
> 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... 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. For a while 
Michal had made it so that the buffer was not flushed until closing. 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...
echo "Closing now"
>
> > You can also switch to the new language mode.
>
> And I have to learn a new language, no? This is what I was saying...

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. It's very barebones basic with point and click 
and pretty much all the same operations so it's familiar. As languages go 
it's designed to be sparse, minimalistic, consistent and clean and it's only 
intended for 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. So it's designed to be a simple solution that 
is at once friendly and easy where anything can be resolved with the function 
browser. Again, it's only intended for simple solutions and logic flow.
>
> > Local variables are not available when using @ functions.
>
> Great, and I cannot mix bash variables with @ functions. So either I use
> globals everywhere, or I learn a new language, which you claim is buggy
> as well.

I have found bugs in the new parser with handling types which mean that it is 
not possible to make a good calculator. There may be others, but if we're 
lucky some of our users will help us to debug and refine this... (Ahem!! 
Cough cough) which will be great because it will be the tool to add 
functionality to features with object templates. ;-)
>
> > > 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
>
> 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.
>
> > 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.
>
> And is this documented?

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.
>
> > > 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.
>
> Wrong.
> @forEach(i, @global(files))
>  @debug(@i)
> @endfor
>
> Just works.

Really? Where's Michal?
>
> 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.
>
> > There is some error reporting now. It could use improvement but it's
> > not too bad.
>
> Well, it did not help me.

Good thing I'm here. ;-)
>
> > 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.
>
> That is just some extra. The problem is with the basics.
>
> > I've also asked in the past if you might help us with the editor.
>
> That's also something else.
>
> > 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
>
> Does not work, because structural flow depends on variables and the same
> variables might be needed in the operations.

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.
>
> > 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.
>
> Again, this is extra and it reduces the cooperation with script
> languages to the level that "you can execute any script". You can do
> this in any language, as every language has some kind of "exec"
> function.
>
> Andras
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. It could be done with 
threads and semaphores but I'm not sure a simple interface could be done for 
users. Alternately since Kommander uses DCOP internally you could use a DCOP 
enabled language. What I'd like to do is to focus on making Kommander 
extensible using Kommander. This would mean that developers using different 
languages could build various tools for general use in Kommander as well as 
extending it's functionality with a particular language. This would be the 
ultimate achievement.

Okay, let's get your camera working, but please step back and look at the 
bigger picture here. Languages are devicive. Language neutrality is 
exceedingly difficult. If we can succeed with the various features and 
functionality I have been talking about then Kommander could become an 
extremely successful tool.

Attached is a dialog to try.
-- 
Eric Laffoon
Project Lead - kdewebdev module
-------------- next part --------------
A non-text attachment was scrubbed...
Name: andrasphoto.kmdr
Type: application/x-kommander
Size: 6183 bytes
Desc: not available
Url : http://momo.creolmail.org/pipermail/kommander-devel/attachments/20050919/8b71b5ad/andrasphoto-0001.bin